目录

一、hash 模式

二、history模式

三、俩者区别

四、重点问题

一、hash 模式

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

注意：

  • hash值为url中#后面的部分，可用window.location.hash获取
  • hash变化会触发网页跳转，即浏览器的前进和后退。
  • hash 可以改变 url ，但是不会触发页面重新加载（hash的改变是记录在 window.history 中），即不会刷新页面。所有页面的跳转都是在客户端进行操作，不算是 http 请求，所以这种模式不利于 SEO 优化。
  • hash 通过 window.onhashchange 的方式，来监听 hash 的改变，借此实现无刷新跳转的功能。
  • hash 只能修改 # 后面的部分，所以只能跳转到与当前 url 同文档的 url 。即使刷新页面hash 也不会提交到 server 端（区别与history模式）。

二、history模式

    history API 是 H5 提供的新特性，允许开发者直接更改前端路由（更新浏览器 URL 地址），而不重新发起请求。但刷新页面时会！

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


hash与history nginx 配置_nginx

        调用这几种方式时，都会只是修改了当前页面的 URL，页面的内容没有任何的变化。但前 3 个方法只是路由历史记录的前进或者后退，无法跳转到指定的 URL；而pushState和replaceState可以跳转到指定的 URL。 通过history的api调整，并不会向后端发起请求，所以也就达到了前端路由的目的。

三、俩者区别

  • hash模式url较丑但兼容IE8以上，而history只兼容IE10以上
  • pushState设置的新URL可以是与当前URL同源的任意URL；而hash只可修改#后面的部分，故只可设置与当前同文档的URL
  • pushState可以设置与当前一模一样的新URL，且会把记录添加到栈中；而hash须设置与原来不一样的url才会添加到栈中
  • pushState通过stateObject可以添加任意类型的数据到记录中；而hash只可添加短字符串

四、重点问题

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