关于前端:前端路由

后端路由: 后端服务器依据 url 地址找到对应的 html 文件，而后把该页面文件发送给浏览器。
前端路由 spa: url 变动，更新页面组件，但不心愿向服务器发送 url 资源申请

两种形式：hash、history

hash:

window.location.hash    # 取值或赋值
window.onhashchange()    # 监听变动 

扭转 hash 的形式：

• 浏览器地址栏手动更改
• location.hash=
• a 标签锚定指定 name 的 a, 或指定 id 的任意标签

都反映在浏览器 url 上，都更改 location.hash 值，且都触发 hashchange

hash 模式须要留神：

• hash 值不会随 http 申请发送到服务器
• 只批改浏览器的 hash 局部，按下回车，浏览器不会发送任何申请给服务器，只会触发 hashchange 事件并且批改 location.hash 的值
• hash 模式下，手动刷新页面不会向浏览器发送申请，不会触发 hashchange 事件，然而会触发 window.onload 事件
• hash 写入时，会在不重载网页的前提下，发明一条拜访历史记录，应用 ” 后退 ” 按钮，就能够回到上一个地位。上述规定对 IE 6 和 IE 7 不成立，它们不会因为 #的扭转而减少历史记录。

history：

history.pushState(stateObj,title,url)
history.replaceState(stateObj,title,url)

history.back()、forward()、go()
window.onpopstate()
history.state # 堆栈最上层的状态值，以后历史记录的状态对象 

history 模式须要留神：

• pushState 会减少一条新的历史记录，而 replaceState 则会替换以后的历史记录，两个 API 都会操作浏览器的历史记录，而不会引起页面的刷新。
• 浏览器的后退与后退（按钮、back、forward、go），会触发 window.onpopstate 事件。
• 超出栈的 go back 不会触发 onpopstate
• state 对象最大 640k，否则异样
• popstate 事件的回调函数中获取以后的历史记录的状态对象的拷贝。然而，这两个对象并不相同，简略的说 e.state 是 history.state 的深拷贝。

两种模式的差别 & 须要留神：

1. hash 模式只能够更改 # 前面的内容，因而只能设置与以后 URL 同文档的 URL；
   History 模式能够通过 pushState() API 设置任意的同源 URL；
2. hash 设置的新值必须与原来不一样才会触发动作将记录增加到栈中；Hash 模式下，屡次刷新为同一个页面的话，记录只增加一次；
   history.pushState() 设置的新 URL 能够与以后 URL 截然不同，这样也会把记录增加到栈中；
3. hash 模式只能更改哈希值，也就是字符串；
   History 模式能够通过 pushState() stateObject 参数能够增加任意类型的数据到记录中；
4. pushState() 可额定设置 title 属性供后续应用，目前没有用。

当然啦，history 也不是样样都好。SPA 尽管在浏览器里熟能生巧，但真要通过 URL 向后端发动 HTTP 申请时，两者的差别就来了。尤其在用户手动输出 URL 后回车，或者刷新（重启）浏览器的时候。

• hash 模式下，仅 hash 符号之前的内容会被蕴含在申请中，模式无需后端配置，并且兼容性好。
• history 模式，前端的 URL 必须和理论向后端发动申请的 URL 统一，如果后端短少对 /book/id 的路由解决，将返回 404 谬误。后端须要配置 index.html 页面用于匹配不到动态资源的时候，或者开启 NGINX 配置

hashchange、popstate 触发条件：

同时触发

loaction.hash =‘’

都不触发 ，即便当 pushState 函数设置 url 参数的值为 hash 格局时，也不会触发 hashchange 事件

history.pushstate({},'','history’)
history.replacestate({},'','history’)

触发 popstate，有 hash 扭转会触发 hashchange

 按钮、history.go、back、forward

注意事项：超出栈的 go back 不会触发 popstate