前端路由基于 JavaScript 拦截 URL 变化实现无刷新导航，依赖 history.pushState 和 popstate；后端路由由服务器响应真实 HTTP 请求返回 HTML 或数据，二者分属不同层级，混用易致白屏、SEO 失效、404 等问题。
前端路由靠 JavaScript 拦截 URL 变化、不刷新页面；后端路由由服务器响应真实 HTTP 请求、返回完整 HTML 或数据。两者根本不在同一层工作，混用或误判会导致白屏、SEO 失效、404 等问题。
前端路由怎么用 history.pushState 和 popstate 手动实现
现代前端框架的路由底层大多基于此 API。它不触发页面刷新，只改变地址栏 URL 并把状态压入浏览器历史栈。
关键点：
-
pushState第一个参数是任意对象（如{page: 'user', id: 123}），会被存入历史记录，但不会自动序列化到 URL 中 - 第二个参数（
title）目前所有主流浏览器都忽略，传空字符串即可 - 第三个参数是新 URL 路径，必须同源，且不能跨域或写成绝对外部地址（否则报错
SecurityError） - 监听
popstate事件才能捕获前进/后退动作，但注意：该事件 不会 在pushState或replaceState时触发
window.history.pushState({ page: 'detail' }, '', '/item/42');
window.addEventListener('popstate', (e) => {
console.log(e.state); // { page: 'detail' }
renderView(e.state.page);
});
为什么 vue-router 或 react-router 不直接用 hash 了
早期用 #（如 /#/user）是为了兼容不支持 pushState 的老浏览器。现在除 IE9 及更早外，所有环境都支持 history 模式，但要注意服务端配合。
立即学习“Java免费学习笔记（深入）”；
常见坑：
- 启用
history模式后，用户直接访问/user/123会 404 —— 因为服务器没这个静态文件，必须配置服务端将所有非资源请求 fallback 到index.html - Nginx 示例配置中漏掉
try_files $uri $uri/ /index.html;，导致刷新即 404 - Vite 开发服务器默认已处理，但生产部署到 Nginx/Apache 时极易忘记配
后端路由返回的是什么，前端路由“假装”返回了什么
后端路由（如 Express 的 app.get('/api/users', ...)）真正响应 HTTP 请求，返回内容类型由 Content-Type 决定：可能是 text/html（完整页面）、application/json（API 数据），甚至 image/png。
前端路由只是 JS 控制视图切换，它：
- 不会发起新的 HTTP 请求（除非你手动
fetch） - 不改变服务器接收到的请求路径（服务器永远只看到首次加载的
/或入口页） - 渲染的内容完全来自本地 JS bundle，搜索引擎爬虫默认不执行 JS，所以纯前端路由的页面若无 SSR/SSG，SEO 几乎为零
真正需要服务端参与的场景（如权限校验、首屏数据注入、SEO），前端路由只能做展示层，核心逻辑仍得靠后端路由兜底。
最易被忽略的一点：前端路由无法替代服务端鉴权。URL 改成 /admin 只是 JS 层面跳转，只要没发请求验证身份，用户就能靠改地址栏绕过——真正的权限控制必须在后端路由或 API 接口里做。
