后端路由: 后端服务器依据 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