序言
其实，hsah和history在前端面试中是很常见的一道题目，本人以前对 hash 和history的认知可能就在 hash 的yrl里面多了一个 # ，而history就不会。然后，本人认知里还有一个是只有history才能做前后端分离，其实对于前端路由来说， hash和history都可以用于前后端分离项目，每个都有自己独特的特点和使用场景
SPA单页面应用
SPA，即单页面应用(Single Page Application)。所谓单页 Web 应用，就是只有一张 Web 页面的应用。单页应用程序 (SPA) 是加载单个 HTML 页面并在用户与应用程序交互时动态更新该页面的 Web 应用程序。浏览器一开始会加载必需的 HTML 、 CSS 和 JavaScript ，所有的操作都在这张页面上完成，都由 JavaScript 来控制。
现如今，为了配合单页面 Web 应用快速发展的节奏，各类前端组件化技术栈层出不穷。近几年来，通过不断的版本迭代， vue 和 react 两大技术栈脱颖而出，成为当下最受欢迎的两大技术栈。
如果页面需要跳转，那么就会用到路由
了解url的组成
| 属性 | 含义 |
|---|---|
| location.protocal | 协议 |
| location.hostname | 主机名 |
| location.host | 主机 |
| location.port | 端口号 |
| location.patchname | 访问页面 |
| location.search | 搜索内容 |
| location.hash | 哈希值 |
//http://127.0.0.1:8001/01-hash.html?a=100&b=20#/aaa/bbb
location.protocal // 'http:'
localtion.hostname // '127.0.0.1'
location.host // '127.0.0.1:8001'
location.port //8001
location.pathname //'01-hash.html'
location.serach // '?a=100&b=20'
location.hash // '#/aaa/bbb'
hash路由
hash 路由是一种把前端路由的路径用井号 # 拼接在真实 url 后面的模式。当井号 # 后面的路径发生变化时，浏览器并不会重新发起请求，而是会触发 onhashchange 事件。
hash的特点
- hash变化会触发网页跳转，即浏览器的前进和后退。
- hash 可以改变 url ，但是不会触发页面重新加载（hash的改变是记录在 window.history 中），即不会刷新页面。也就是说，所有页面的跳转都是在客户端进行操作。因此，这并不算是一次 http 请求，所以这种模式不利于 SEO 优化。hash 只能修改 # 后面的部分，所以只能跳转到与当前 url 同文档的 url 。
- hash 通过 window.onhashchange 的方式，来监听 hash 的改变，借此实现无刷新跳转的功能。
- hash 永远不会提交到 server 端（可以理解为只在前端自生自灭）
History路由
history API 是 H5 提供的新特性，允许开发者直接更改前端路由，即更新浏览器 URL 地址而不重新发起请求。
与hash的区别
//正常页面浏览
https://github.com/xxx 刷新页面
https://github.com/xxx/yyy 刷新页面
https://github.com/xxx/yyy/zzz 刷新页面
//history模式
https://github.com/xxx 刷新页面
https://github.com/xxx/yyy 前端跳转，不刷新页面
https://github.com/xxx/yyy/zzz 前端跳转，不刷新页面
history的特点
- 新的 url 可以是与当前 url 同源的任意 url ，也可以是与当前 url 一样的地址，但是这样会导致的一个问题是，会把重复的这一次操作记录到栈当中
- 通过 history.state ，添加任意类型的数据到记录中
- 可以额外设置 title 属性，以便后续使用。
- 通过 pushState 、 replaceState 来实现无刷新跳转的功能
存在问题
- 使用 history 模式时，在对当前的页面进行刷新时，此时浏览器会重新发起请求。如果 nginx 没有匹配得到当前的 url ，就会出现 404 的页面。
- 而对于 hash 模式来说， 它虽然看着是改变了 url ，但不会被包括在 http 请求中。所以，它算是被用来指导浏览器的动作，并不影响服务器端。因此，改变 hash 并没有真正地改变 url ，所以页面路径还是之前的路径， nginx 也就不会拦截
- 因此，在使用 history 模式时，需要通过服务端来允许地址可访问，如果没有设置，就很容易导致出现 404 的局面。