两种模式

前端路由的核心,就在于 —— 改变视图的同时不会向后端发出请求。

  • hash模式是通过改变锚点(#)来更新页面URL,并不会触发页面重新加载,我们可以通过window.onhashchange监听到hash的改变,从而处理路由。
  • history模式是通过调用window.history对象上的一系列方法来实现页面的无刷新跳转。

特点

hash
hash,原本用来结合锚点控制页面视窗的位置,具有以下特点:

  • 可以改变URL,但不会触发页面重新加载(hash的改变会记录在window.hisotry中)因此并不算是一次http请求,所以这种模式不利于SEO优化
  • 只能修改#后面的部分,因此只能跳转与当前URL同文档的URL
  • 只能通过字符串改变URL
  • 通过window.onhashchange监听hash的改变,借此实现无刷新跳转的功能。

history
根据 Mozilla Develop Network 的介绍,调用 history.pushState()相比于直接修改 hash,存在以下优势

  • 新的URL可以是与当前URL同源的任意 URL,也可以与当前URL一样,但是这样会把重复的一次操作记录到栈中
  • 通过参数stateObject可以添加任意类型的数据到记录中
  • 可额外设置title属性供后续使用
  • 通过pushStatereplaceState实现无刷新跳转的功能。

存在问题
当应用通过vue-router跳转到某个页面后,因为此时是前端路由控制页面跳转,虽然url改变,但是页面只是内容改变,并没有重新请求,所以这套流程没有任何问题。但是,如果在当前的页面刷新一下,此时会重新发起请求,如果nginx没有匹配到当前url,就会出现404的页面。那为什么hash模式不会出现这个问题呢?因为hash虽然可以改变URL,但不会被包括在HTTP请求中。它被用来指导浏览器动作,并不影响服务器端,因此,改变hash并没有改变url,所以页面路径还是之前的路径,nginx不会拦截。
因此,切记在使用history模式时,需要服务端允许地址可访问,否则就会出现404的尴尬场景。

总结

  • hash模式下,所有的页面跳转都是客户端进行操作,因此对于页面拦截更加灵活;但每次url的改变不属于一次http请求,所以不利于SEO优化。
  • history模式下,借助history.pushState实现页面的无刷新跳转;这种方式URL的改变属于http请求,因此会重新请求服务器,这也使得我们必须在服务端配置好地址,否则服务端会返回404,为确保不出问题,最好在项目中配置404页面。
Logo

前往低代码交流专区

更多推荐