两种模式

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

• 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属性供后续使用
• 通过pushState、replaceState实现无刷新跳转的功能。

存在问题
当应用通过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页面。