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