前端路由靠浏览器 API 实现，核心是 history.pushState() 和 popstate 事件（History 模式），或 hashchange 事件（Hash 模式）；需手动处理路径匹配、状态更新与服务端 fallback 配置。
前端路由靠什么实现？不是服务器，是浏览器 API
前端路由不依赖后端响应，核心靠 history.pushState() 和 history.replaceState() 修改 URL 而不刷新页面，再配合 popstate 事件监听前进/后退。Hash 模式则用 location.hash 变化触发 hashchange 事件——兼容性更好，但 URL 里会多出 #。
怎么手动写一个最小可用的 history 路由
不用框架也能跑起来，关键三步：
- 初始化时读取
location.pathname，匹配对应组件或回调 - 监听
popstate事件，每次触发都重新匹配路径 - 封装
push()方法：调用history.pushState()+ 手动触发匹配逻辑（popstate不会主动触发首次加载）
示例片段：
function route(path, handler) {
if (location.pathname === path) handler();
}
function push(path) {
history.pushState({}, '', path);
route(path, () => console.log('navigated to', path));
}
window.addEventListener('popstate', () => {
route(location.pathname, () => console.log('popped to', location.pathname));
});
为什么 pushState 后服务刷新 404？服务端要配 fallback
History 模式下，用户直接访问 /dashboard，请求会发到服务端——但这个路径前端才管，后端通常没对应文件。解决方法不是改前端，而是让服务端把所有非静态资源的请求，都返回 index.html（即前端入口）。Nginx 配置关键行：try_files $uri $uri/ /index.html;；Vite 开发服务器默认已处理，但 build 部署到 Nginx/Apache 时必须手动加。
立即学习“Java免费学习笔记（深入）”；
Hash 模式真能绕过 404 吗？它有别的代价
Hash 模式确实不触发服务端请求，所以部署零配置。但它的问题更隐蔽：
- SEO 友好性差：搜索引擎普遍不索引
#后的内容 - 无法使用
scrollRestoration: 'auto'等现代 History API 特性 - 第三方分享链接带
#显得不专业，且某些代理或安全策略会过滤 hash -
location.hash值始终带#前缀，字符串处理容易漏掉
现在绝大多数新项目应优先选 History 模式，只在明确需要兼容 IE9 或部署环境完全不可控时退回到 Hash。
真正难的不是写几行路由代码，而是理解 URL 变化和 DOM 更新之间谁该触发谁、服务端和前端责任边界在哪、以及用户从地址栏输入路径时整个链路怎么走通——这些地方一错，调试起来比写逻辑还耗时。
