共计 1040 个字符，预计需要花费 3 分钟才能阅读完成。
先解释下基本概念
hash
hash 不是那个哈希算法，就是以前 url 用的锚点，以前是多用来定位页面展示内容。代表符号是“#”
之所以用 hash 是因为他既可以获取到，又可以不去刷新页面也不去请求服务器。满足单页面的需求。
一般写法: 就如说我们的思否 https://segmentfault.com/#a/b… 你在控制台输入 window.location.hash，就会出现 #a/b/c/d
history
就是 url，也比如说我们的思否, 我现在写文章的页面 https://segmentfault.com/write，你在浏览器输入 window.location.pathname 就会输出 /write，但是单页面路由中的 url 主要目的是用来存储路由变量的
基本概念说完了，说下原理
hash 的原理 比较简单粗暴易理解，因为锚点本身就是基于单页面的一种页面定位功能，获取页面的 hash 值相当于可以直接获取路由的变量，实现按需加载子页面。
history 的原理 略微复杂一点，它可以通过 history.pushState(state, title, url)去变动 url 内容，不会造成页面刷新。这里 state 可以存一些 params 值，title 随便传值吧目前没什么用。url 就是要变动的 url。既然浏览器不会刷新。那么和 hash 就变成一样的效果了, 但是比 hash 美观。
讲一下区别
hash 是一个真实的 url，它利用锚点 #来实现单页面，只要锚点前的地址不会，这个页面就不会刷新, 即便刷新了，也能立即获取到路由参数（# 后面的内容）
history 是一个虚假的 url, 他就像你用代码去在地址栏敲了 url，并且，没按回车 你一旦按了回车，那基本上就崩了，因为浏览器 会真的去请求这个虚假的 url。那么自然就崩了。（前端开发的时候没崩是因为 dev 包把这个问题都解决了，但是生存环境的服务器并没有去主动解决，所以部署以后就崩，所以需要手动解决一下）
然后说一下 history 的解决方法，解决方法有很多，我个人喜欢重定向的方法。
首先 服务器将所有的页面方面的请求均 重定向 到 初始页上面，这样的话，url 就不至于请求不到页面（当然嫌麻烦的可以直接把 404 重定向到初始页面）
然后 在前端最外层页面写一个地址解析（一般框架都应该有写好，我这里是说自己写路由插件），相当于获取到路由所需参数。
这样的话，就可以做到刷新页面不崩的效果。
如果有服务器部署基础的可以拿 nginx 此类的服务器试试，我自己这边是默默地拿着 notepad 配置成功了 ……
