项目中的场景
之前的一个vue项目改用history模式，部署线上后发现某个页面出现了404，经过一番研究，发现和nginx配置的资源路径有关系，但是使用hash模式不会有这种问题， 所以简单记录下这两种模式的区别与关系，避免再踩坑。
两种模式
官网对前端路由的解释
前端路由的核心，就在于 —— 改变视图的同时不会向后端发出请求。
- 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页面
