pushState不会触发页面刷新，因为它仅操作浏览器历史栈、修改URL栏和window.location，不发起导航请求或重新加载文档，DOM与JS上下文完全保留；需手动监听popstate事件并同步视图，且服务端须配置fallback避免404。
pushState 为什么不会触发页面刷新
因为 pushState 只是操作浏览器历史栈，不发起导航请求，也不重新加载文档。它只改 URL 栏、更新 window.location，但 DOM 和 JS 上下文完全保留——这是单页应用（SPA）实现“无跳转换页”的底层前提。
常见错误现象：调用 pushState 后地址变了，但后续点击浏览器后退/前进按钮没反应，或触发了整页 reload。这通常是因为没监听 popstate 事件，或监听了但没正确同步视图状态。
- 必须手动监听
popstate事件来响应后退/前进 -
pushState的第三个参数（url）必须是同源的相对路径或绝对路径；传入跨域 URL 会静默失败 - 如果传入的
url是相对路径（如"./user/123"），浏览器会基于当前 URL 解析，不是基于<base>标签
pushState 的三个参数怎么填才安全
调用形式是 history.pushState(state, title, url)，其中 title 在现代浏览器中基本被忽略（可传空字符串），真正关键的是 state 和 url。
-
state应为可序列化的对象（如{page: "user", id: 123}），不能是函数、DOM 节点或包含循环引用的对象，否则序列化时会报错或丢失数据 -
url必须与当前页面同源；例如当前在https://example.com/app/，可传"/app/user/456"或"user/456"，但不能传"https://other.com/xxx" - 若
url是相对路径，建议统一用以/开头的绝对路径（如"/user/456"），避免因当前 URL 路径层级不同导致解析歧义
示例：
history.pushState({page: "post", id: 789}, "", "/post/789");
popstate 事件监听必须在初始化时就注册
很多人把 popstate 监听写在某个路由切换函数内部，结果只有首次进入页面后才能响应后退——这是错的。该事件需全局、尽早绑定，且应与 SPA 的路由状态管理逻辑耦合。
- 监听应在页面加载完成（
DOMContentLoaded）或应用启动时立即注册，不要延迟到某次pushState之后 - 事件回调中应从
event.state提取数据，并驱动视图更新；不要依赖window.location.pathname做判断（因为pushState后它已更新，但视图未必同步） - 注意：页面首次加载时（非通过后退/前进）不会触发
popstate，所以初始路由匹配逻辑要单独处理
示例：
window.addEventListener("popstate", (e) => {
if (e.state && e.state.page === "user") {
renderUserPage(e.state.id);
}
});
和 HTML5 History API 配合的几个易忽略细节
单独用 pushState 很容易踩坑，尤其在服务端未配合时。
- 服务端必须对所有可能的前端路由返回同一份 HTML（通常是
index.html），否则用户直接访问/dashboard会 404 - 不要在
pushState后再调用location.hash = "..."，二者混用会导致历史栈混乱 - 调试时可用
history.length和history.state检查当前栈状态；但注意history.state只反映当前条目的 state，不是整个栈 - 部分老版本 Safari 对
pushState的state对象大小有限制（约 640KB），超限会静默截断
复杂点在于：URL 变更本身是轻量的，但让它真正“可预测、可回溯、可分享”，需要 state 数据、视图渲染、服务端配置三者严格对齐——漏掉任何一环，都会在用户刷新或分享链接时暴露问题。
