history.pushState仅修改URL和历史栈而不触发跳转或加载页面，需手动实现路由匹配、视图更新及服务端fallback支持。
history.pushState 本身不触发跳转，也不加载新页面——它只改 URL 和浏览器历史，真正的“跳转效果”必须由你手动实现。
为什么调用 pushState 后页面没变化
这是最常被误解的一点：pushState 不会触发路由匹配、不执行任何渲染逻辑、也不会自动加载 HTML 或 JS。它只是静默修改地址栏和历史栈。
- 浏览器不会向服务器发请求，也不会解析新 URL 对应的资源
- 你需要监听
popstate事件来响应后退/前进，并自己决定渲染什么内容 - URL 改变后，若用户刷新页面，服务端必须能返回同一份 HTML（否则 404）
如何配合前端路由实现无刷新切换
核心是三步闭环：URL 变更 → 状态记录 → 视图更新。例如用原生 JS 实现一个简易路由：
// 记录状态并更新 URL
function navigate(path) {
history.pushState({ path }, '', path);
renderView(path); // 你自己的渲染函数
}
// 响应浏览器前进/后退
window.addEventListener('popstate', (e) => {
renderView(e.state?.path || '/');
});
// 初始加载也要渲染一次
renderView(window.location.pathname);
-
renderView必须是纯前端逻辑：比如切换<div> 显示隐藏、用 <code>fetch加载模板、或替换innerHTML - 注意
pushState的第一个参数（state对象）不能含函数或 DOM，序列化时会被丢弃 - 第二个参数（
title）目前所有主流浏览器都忽略，传空字符串即可 - Node.js（Express）示例：
app.get('*', (req, res) => res.sendFile(indexHtmlPath)) - Nginx 配置关键行：
try_files $uri $uri/ /index.html; - Vercel/Netlify 等平台通常默认开启 SPA fallback，但需确认
_redirects或vercel.json未覆盖 - 调用
pushState前没做 URL 标准化（如多余斜杠、大小写、编码），导致相同页面生成多条历史记录 - 未在
popstate回调中阻止默认行为（虽然它本来就不刷新，但习惯性加e.preventDefault()是误区） - 异步渲染未完成时用户快速点击多次，
pushState被连发，但state对象可能滞后于实际 UI 状态 - SPA 中嵌入 iframe 或第三方 SDK（如微信 JS-SDK），它们可能依赖
location.href，而pushState不触发其监听
服务端必须支持“同构 fallback”
单页应用的 URL 如 /user/123 是前端路由，但用户直接访问该地址时，浏览器会向服务端发起请求。如果服务端没配置 fallback，就会返回 404。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的边界问题
真实项目里，这几个点常导致白屏、重复请求或历史错乱：
真正让“无刷新跳转”生效的，从来不是 pushState 这一行代码，而是它前后那一整套状态同步、视图响应和服务端兜底的协作链条。漏掉任意一环，用户看到的就是卡死、白屏或 404。
