前端路由基于 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 模式，但要注意服务端配合。

常见坑：

• 启用 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 接口里做。