单页应用路由本质是用history.pushState/replaceState改URL并操作历史栈，配合popstate监听导航，需服务端兜底返回index.html且前端主动匹配初始路径。
单页应用的路由本质是监听 URL 变化，不刷新页面
浏览器地址栏变了，但页面没重载——这靠的是 history.pushState() 和 history.replaceState() 操作浏览器历史栈，配合 popstate 事件监听返回/前进。不是靠服务端跳转，也不是靠 iframe 假跳转。
关键点：pushState() 不触发页面刷新，也不触发 load 或 hashchange；它只改 URL、存状态、加一条历史记录。
- 必须用
event.preventDefault()阻止的默认跳转，否则页面真刷新 -
popstate事件只在用户点击浏览器「后退」「前进」按钮，或调用history.back()时触发，不会在pushState()后立刻触发 - 服务端必须配置：所有前端路由路径都返回同一份
index.html（否则刷新 404）
手写一个最小可用的 client-side router
不需要框架，10 行内可跑通基础路由切换。核心是三件事：注册路由表、劫持链接点击、响应 URL 变化。
const routes = {
'/': () => document.body.innerHTML = 'Home
',
'/about': () => document.body.innerHTML = 'About
',
'/user': () => document.body.innerHTML = 'User
'
};
const navigate = (url) => {
history.pushState({ url }, '', url);
routes[url]?.();
};
window.addEventListener('popstate', e => routes[e.state?.url]?.());
document.addEventListener('click', e => {
if (e.target.matches('a[data-router]')) {
e.preventDefault();
navigate(e.target.href.split(window.location.origin)[1]);
}
});
注意：data-router 是自定义属性，用于区分哪些链接交给 JS 路由处理；e.target.href.split(window.location.origin)[1] 是为兼容完整 URL，提取 pathname 部分。
为什么不能只依赖 hash 路由？
location.hash 确实能避开刷新，但有硬伤：SEO 不友好、服务端无法感知、URL 中带 # 显得过时。现代 SPA 几乎全用 history 模式。
- hash 变化触发
hashchange，无需pushState，但 URL 是https://site.com/#/user，不是https://site.com/user - 服务端对
/#anything一律返回 200，所以 hash 路由部署简单，但不利于 SSR 和预渲染 - 部分老系统（如 IE9）不支持
pushState，此时 hash 是降级方案，不是首选
刷新后如何恢复页面状态？
用户直接访问 /user 或按 F5，浏览器会向服务端请求该路径——此时前端 JS 尚未执行，必须靠服务端兜底返回 index.html，再由
location.pathname 手动匹配路由。
也就是说，首次加载时没有 popstate，要主动执行一次：
const currentPath = window.location.pathname; routes[currentPath]?.();
这个逻辑必须放在脚本最开头，否则白屏几毫秒。如果路由逻辑复杂（比如要异步加载组件），就得搭配 DOMContentLoaded 或 defer 加载脚本，但别等 load——太晚。
真正容易被忽略的是：服务端配置错误导致刷新 404，比 JS 写错更难排查；而前端忘记处理初始路径，会导致首屏空白，且控制台无报错。
