hash 和 history 路由

hash 模式

        hash 路由：监听 url 中 hash 的变化，然后渲染不同的内容，这种路由不向服务器发送请求，不需要服务端的支持；类似锚点用来定位页面展示内容，代表符号是“#”（url难看）# 拼接在真实 url 后面的模式。当井号 # 后面的路径发生变化时（获取页面的hash值相当于可以直接获取路由的变量），浏览器并不会重新发起请求，而是会触发 onhashchange 事件，实现按需加载子页面。

注意：

hash变化会触发网页跳转，即浏览器的前进和后退。

hash 可以改变 url ，但是不会触发页面重新加载（hash的改变是记录在 window.history 中），即不会刷新页面。也就是说，所有页面的跳转都是在客户端进行 *** 作。因此，这并不算是一次 http 请求，所以这种模式不利于 SEO 优化。hash 只能修改 # 后面的部分，所以只能跳转到与当前 url 同文档的 url 。

hash 通过 window.onhashchange 的方式，来监听 hash 的改变，借此实现无刷新跳转的功能。

hash 永远不会提交到 server 端

  history模式

    history API 是 H5 提供的新特性，允许开发者直接更改前端路由，即更新浏览器 URL 地址而不重新发起请求。

H5 的 window.history中的方法，常见的 *** 作有：

back()：后退到上一个路由；forward()：前进到下一个路由，如果有的话；go(number)：进入到任意一个路由，正数为前进，负数为后退；pushState(obj, title, url)：前进到指定的 URL，不刷新页面；replaceState(obj, title, url)：用 url 替换当前的路由，不刷新页面；

调用这几种方式时，都会只是修改了当前页面的 URL，页面的内容没有任何的变化。但前 3 个方法只是路由历史记录的前进或者后退，无法跳转到指定的 URL；而pushState和replaceState可以跳转到指定的 URL。如果有面试官问起这个问题“如何仅修改页面的 URL，而不发送请求”，那么答案就是这 5 种方法。

存在的问题：

对于 history 来说，确实解决了不少 hash 存在的问题，但是也带来了新的问题。具体如下：

使用 history 模式时，在对当前的页面进行刷新时，此时浏览器会重新发起请求。如果 nginx 没有匹配得到当前的 url ，就会出现 404 的页面。而对于 hash 模式来说， 它虽然看着是改变了 url ，但不会被包括在 http 请求中。所以，它算是被用来指导浏览器的动作，并不影响服务器端。因此，改变 hash 并没有真正地改变 url ，所以页面路径还是之前的路径， nginx 也就不会拦截。因此，在使用 history 模式时，需要通过服务端来允许地址可访问，如果没有设置，就很容易导致出现 404 的局面。