前端常见问题以及处理方式 - - - （二）前端路由的两种模式和区别

提示：前端查漏补缺，仅代表个人观点，不接受如何批评

---

一、前端路由实现了什么？

• 从用户角度看 前端路由实现了两个功能（使用ajax更新页面状态的情况下）

   1、`记录当前页面的状态`（保存或分享当前页的url，再次打开该url时，网页还是保存的（分享）时的状态）；
   
   2、`可使用浏览器的前进后退功能`（如点击后退按钮，可以使页面回到ajax更新页面之前的状态，url也回到之前的状态）
  

---

• 作为开发者，要实现这两个功能，我们需要做到：

   1、改变url且不让浏览器向服务器发出请求；
   2、监测url的变化；
   3、截获url地址，并解析出需要的信息来匹配路由规则。
  

二、hash模式

1.介绍

• 这里的hash就是指url尾巴后的#号以及后面的字符。这里的#和css里的#是一个意思。hash也称作锚点，本身是用来做页面定位的，他可以使对应的id元素显示在可视区域内。

• 由于hash值变化不会导致浏览器向服务器发出请求，而且hash改变会触发hashchange事件，浏览器的进后退也能对其进行控制，所以人们在html5的history出现前，基本都是使用hash来实现前端路由的。他的特点在于：hash虽然出现url中，但不会被包含在HTTP请求中，对后端完全没有影响，因此改变hash不会重新加载页面。hash 本来是拿来做页面定位的，如果拿来做路由的话，原来的锚点功能就不能用了。

• 其次，hash的而传参是基于url的，如果要传递复杂的数据，会有体积的限制

示例代码：

window.location.hash='qq'//设置 url 的 hash，会在当前url后加上'#qq'

var hash = window.location.hash //'#qq'

window.addEventListener('hashchange',function(){
  //监听hash变化，点击浏览器的前进后退会触发
})

2.特点

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

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

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

• hash 永远不会提交到 server 端（可以理解为只在前端自生自灭）。

---

三.history模式

1.介绍

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

• history模式不仅可以在url里放参数，还可以将数据存放在一个特定的对象中。

• history———利用了HTML5 History Interface 中新增的pushState（）和replaceState（）方法。（需要特定浏览器的支持）history不能运用与IE8一下

示例代码：

window.history.pushState(state,title,url)
//state：需要保存的数据，这个数据在触发popstate事件时，可以在event.state里获取
//title：标题，基本没用，一般传null
//url：设定新的历史纪录的url。新的url与当前url的origin必须是一样的，否则会抛出错误。url可以时绝对路径，也可以是相对路径。
//如 当前url是 https://www.baidu.com/a/,执行history.pushState(null, null, './qq/')，则变成 https://www.baidu.com/a/qq/，
//执行history.pushState(null, null, '/qq/')，则变成 https://www.baidu.com/qq/

window.history.replaceState(state,title,url)
//与pushState 基本相同，但她是修改当前历史纪录，而 pushState 是创建新的历史纪录

window.addEventListener("pospstate",function(){
 //监听浏览器前进后退事件，pushState与replaceState方法不会触发
})
window.history.back()//后退
window.history.forward()//前进
window.history.go(1)//前进一部，-2回退两不，window.history.lengthk可以查看当前历史堆栈中页面的数量

2.特点

• 新的 url 可以是与当前 url 同源的任意 url ，也可以是与当前 url 一样的地址，但是这样会导致的一个问题是，会把重复的这一次操作记录到栈当中。

• 通过 history.state ，添加任意类型的数据到记录中。

• 可以额外设置 title 属性，以便后续使用。

• 通过 pushState 、 replaceState 来实现无刷新跳转的功能。

3.history存在问题

• 使用 history 模式时，在对当前的页面进行刷新时，此时浏览器会重新发起请求。如果 nginx 没有匹配得到当前的 url ，就会出现 404 的页面。

• 而对于 hash 模式来说， 它虽然看着是改变了 url ，但不会被包括在 http 请求中。所以，它算是被用来指导浏览器的动作，并不影响服务器端。因此，改变 hash 并没有真正地改变 url ，所以页面路径还是之前的路径， nginx 也就不会拦截。

• 因此，在使用 history 模式时，需要通过服务端来允许地址可访问，如果没有设置，就很容易导致出现 404 的局面。

---

三.404错误

• 1、hash模式下，仅hash符号之前的内容会被包含在请求中，如 http://www.abc.com 因此对于后端来说，即使没有做到对路由的全覆盖，也不会返回404错误；
• 2、history模式下，前端的url必须和实际后端发起请求的url一致，如http://www.abc.com/book/id 。如果后端缺少对/book/id 的路由处理，将返回404错误

---

总结

---

---

• 这两个方法应用于浏览器的历史纪录站，在当前已有的back、forward、go 的基础之上，他们提供了对历史纪录进行修改的功能，只是当他们执行修改使，虽然改变了当前的url，但你的浏览器不会立即像后端发送请求。

• To B 的系统推荐用 hash ，相对简单且容易使用，且因为 hash 对 url 规范不敏感；

• To C 的系统，可以考虑选择 H5 history ，但是需要服务端支持；