前端路由原理总结
hash路由(vue中的createWebHashHistory react中的HashRouter)
监听 url 中 hash 的变化，然后渲染不同的内容，这种路由不向服务器发送请求，不需要服务端的支持；
history路由(vue中的createWebHistory react中的BrowserRouter)
监听 url 中的路径变化，需要客户端和服务端共同的支持；
hash 路由
在 Hash 模式下，URL 中的 hash 值（即 # 号后面的部分）会被用来表示当前页面的状态，而不会引起页面的刷新。因此，使用 hash 模式可以实现无需后端支持即可进行前端路由。
例如，如果我们访问 http://example.com/#/home，则会渲染出 Home 组件，而不会刷新整个页面。如果我们点击链接切换到 http://example.com/#/about，则会渲染出 About 组件，同样不会刷新整个页面。
在 hash 模式下，Vue Router 会监听 URL 中 hash 值的变化，当 hash 值发生变化时，会自动匹配对应的路由并渲染对应的组件。
JS使用hash跳转到url-alan路由
location.hash="url-alan"
当页面中的 hash 发生变化时，会触发hashchange事件，因此我们可以监听这个事件，来判断路由是否发生了变化。
window.addEventListener(
'hashchange',
function (event) {
const oldURL = event.oldURL; // 上一个URL
const newURL = event.newURL; // 当前的URL
console.log(newURL, oldURL);
},
false
);
history 路由
在 History 模式下，URL 中的路径会被用来表示当前页面的状态，而不再需要用 hash 值。使用 History 模式需要后端服务器的支持，因为在刷新页面时，需要向服务器发送请求获取对应的 HTML 页面。
例如，如果我们访问 http://example.com/home，则会渲染出 Home 组件，如果我们点击链接切换到 http://example.com/about，则会渲染出 About 组件，同样不会刷新整个页面。
在 History 模式下，Vue Router 会监听 URL 中路径的变化，当路径发生变化时，会自动匹配对应的路由并渲染对应的组件。
JS使用history跳转到url-alan路由
// history.pushState(state, title, url)
window.history.pushState({},'title','url-alan')
可以使用onpopstate事件监听历史记录的回退
在 history 路由中，我们一定会使用window.history中的方法，常见的操作有：
● back()：后退到上一个路由；
● forward()：前进到下一个路由，如果有的话；
● go(number)：进入到任意一个路由，正数为前进，负数为后退；
● pushState(obj, title, url)：前进到指定的 URL，不刷新页面；
● replaceState(obj, title, url)：用 url 替换当前的路由，不刷新页面；
调用这几种方式时，都会只是修改了当前页面的 URL，页面的内容没有任何的变化。但前 3 个方法只是路由历史记录的前进或者后退，无法跳转到指定的 URL；而pushState和replaceState可以跳转到指定的 URL。如果有人问起这个问题“如何仅修改页面的 URL，而不发送请求”，那么答案就是这 5 种方法。
如果服务端没有新更新的 url 时，一刷新浏览器就会报错，因为刷新浏览器后，是真实地向服务器发送了一个 http 的网页请求。因此若要使用 history 路由，需要服务端的支持。
pushState 和 replaceState 两个方法跟location.href和 location.replace 两个方法有什么区别呢？应用的场景有哪些呢？
- location.href 和 location.replace 切换时要向服务器发送请求，而 pushState 和 replace 仅修改 url，除非主动发起请求；
- 仅切换 url 而不发送请求的特性，可以在前端渲染中使用，例如首页是服务端渲染，二级页面采用前端渲染；
- 可以添加路由切换的动画；
- 在浏览器中使用类似抖音的这种场景时，用户滑动切换视频时，可以静默修改对应的 URL，当用户刷新页面时，还能停留在当前视频。
如何选择hash和history
总的来说，Hash 模式适合开发纯前端应用，不需要服务器的支持，但是 URL 比较丑陋。History 模式适合开发需要 SEO 支持的应用，但是需要服务器的支持，并且需要进行 URL 重写以去除 URL 中的 # 号。
如果你不需要考虑 SEO 问题，或者你的服务器配置不允许 URL 重写，那么可以选择使用 hash 模式；
如果你需要考虑 SEO 问题，或者你的服务器支持 URL 重写，那么可以选择使用 history 模式。