history.pushState 不触发页面跳转，因为它仅修改 URL 和历史栈而不加载新页面，需手动更新视图；适用于 SPA 无刷新导航，配合 popstate 监听实现前进/后退状态恢复。
history.pushState 为什么没触发页面跳转
因为 pushState 本身不加载新页面，它只修改 URL 和历史栈，浏览器不会发起请求或刷新 DOM。常见误用是以为调用后会像 location.href 那样自动渲染新内容——实际需要你手动更新视图（比如重绘组件、加载数据）。
使用场景：单页应用（SPA）中实现无刷新导航，例如点击菜单切换内容但保留浏览器前进/后退功能。
-
pushState第一个参数是 state 对象，会被序列化保存在历史记录里，可用于恢复页面状态 - 第二个参数（title）在多数浏览器中被忽略，可传空字符串
"" - 第三个参数是相对路径（如
"./user/123"），必须同源，否则抛出SecurityError - 调用后
location.href立即改变，但document.body不变——这点常被忽略
history.pushState({ userId: 123, tab: "profile" }, "", "./user/123");
// 此时 URL 变为 https://example.com/user/123，但页面内容未更新
监听 popstate 事件的正确姿势
popstate 只在用户点击前进/后退按钮，或调用 history.back() / history.forward() 时触发，**不会**在 pushState 或 replaceState 时触发。
容易踩的坑：绑定监听太晚（比如等 DOM 加载完才绑），导致页面初始加载时的 history 状态丢失；或者没处理 event.state 为 null 的情况（初始页面通常没有 state）。
立即学习“Java免费学习笔记（深入）”；
- 建议在
<head>中尽早注册监听，或确保在任何pushState前已绑定 -
event.state是之前传入pushState或replaceState的对象副本，可直接读取 - 首次进入页面时，
popstate不会触发，需手动检查history.state并初始化视图
window.addEventListener("popstate", (event) => {
if (event.state) {
renderPage(event.state); // 比如根据 userId 加载用户数据
} else {
renderHomePage(); // 初始页或 fallback
}
});
replaceState 和 pushState 的关键区别
两者参数完全一致，但行为不同：replaceState 替换当前历史记录项，不增加新条目；pushState 总是新增一条。这意味着，连续多次 replaceState 后按一次「后退」会直接跳到上一个 pushState 的位置，而不是逐条回退。
典型使用场景：replaceState 适合修正当前 URL（如移除查询参数、补全 hash）、或避免用户误点后退回到无效中间态；pushState 用于真正的导航动作。
- 搜索框输入时用
replaceState更新 URL 参数，避免每次按键都生成历史项 -
表单提交成功后用
replaceState清除临时状态，防止刷新重复提交 - 不要用
replaceState替代location.reload()—— 它不会重新加载资源
// 用户筛选变化，不希望留下一堆历史记录
history.replaceState({ filters: { type: "active" } }, "", "?type=active");
// 点击文章标题，这是真正的导航，应允许后退
history.pushState({ postId: 456 }, "", "/post/456");
history.state 在页面加载时的可靠性问题
history.state 在页面首次加载时可能为 null（即使 URL 有路径），且无法通过 JS 主动设置初始 state。这意味着不能依赖它来判断“页面是怎么来的”。更可靠的方式是解析 location.pathname 和 location.search 来还原状态。
复杂点在于：服务端直出页面和客户端 SPA 混合时，初始 history.state 往往为空，而后续 pushState 的 state 又只存在于 JS 内存中，刷新即丢失。所以关键逻辑不能只依赖 history.state，得结合 URL 解析做兜底。
