replaceState 不触发页面刷新和 popstate 事件，仅修改当前历史记录；需确保 state 为对象、url 同源且传全三个参数，常用于 SPA 中更新 URL 而不增加历史深度。
replaceState 不触发页面刷新，但必须配合 pushState 使用场景
直接调用 history.replaceState() 是安全的——它只修改当前历史记录条目，不会新增或后退。但很多人发现“没生效”，往往是因为：刚打开页面时，当前条目是初始状态（URL 无变化、state 为空），而你试图用 replaceState() 改一个根本没被 pushState() 或浏览器导航写入过自定义 state 的条目，导致视觉/行为上“像没动”。这不是 bug，是预期行为。
实际使用中，它最常出现在以下情况：
- 表单提交后修正 URL（如从
/search变成/search?q=js），但不想让用户点后退回到空搜索页 - SPA 中切换视图但不希望增加历史深度（比如关闭模态框、收起侧边栏）
- 服务端已跳转，前端再微调 URL 和 state（如补全 utm 参数）
replaceState 的三个参数必须传全，且 state 对象不能为 null
history.replaceState(state, title, url) 三个参数都不可省略（虽然 title 当前多数浏览器忽略，但必须传字符串）。漏掉 url 会抛 TypeError: Failed to execute 'replaceState' on 'History'；传 null 或 undefined 给 state 在部分浏览器（如旧版 Safari）会静默失败。
推荐写法：
立即学习“前端免费学习笔记（深入）”；
history.replaceState(
{ page: 'product', id: 123 }, // 必须是对象或 {}
'', // 传空字符串，避免潜在兼容问题
'/product/123' // 相对路径会被自动解析为绝对 URL
);
注意：url 必须同源，否则报 SecurityError；相对路径会被当前页面 origin 补全，不需要手动拼 window.location.origin。
replaceState 后 window.location.href 立即更新，但 popstate 不触发
这是关键区别：replaceState() 修改的是历史栈当前项，不改变“位置”，所以不会触发 popstate 事件。如果你监听了 popstate 来驱动路由，那它对 replaceState 完全无感——这正是你想要的（不干扰用户后退逻辑）。
验证是否生效？直接看地址栏，或检查：
console.log(window.location.href); // 已变成新 URL console.log(history.state); // 已变成你传入的 state 对象
常见误操作：
- 在
popstate回调里又调replaceState()，造成无限循环（因为 replace 不触发 popstate，但容易和 push 混淆） - 以为 replace 后要手动更新 DOM，其实它只改历史和 URL，DOM 渲染仍需你自行处理（比如渲染新内容、滚动到锚点）
和服务端渲染（SSR）配合时，replaceState 要等 DOM 就绪
如果页面由服务端直出，前端 JS 在 DOMContentLoaded 前就执行 replaceState()，可能因 URL 已被服务端设定而无效（尤其在 Next.js、Nuxt 等框架中，它们内部已用 pushState 初始化路由）。更稳妥的做法是等框架路由就绪后再调用。
例如，在 React Router v6+ 中，不要在组件挂载时直接调 history.replaceState()，而应使用 useNavigate() 配合 { replace: true }：
const navigate = useNavigate();
navigate('/new-path', { replace: true }); // 底层就是 replaceState
原生场景下，确保执行时机：
- 放在
DOMContentLoaded后 - 避开服务端注入的初始
pushState调用（可加setTimeout微任务延迟，或监听load） - 若 URL 已含 query/hash，先解析再替换，避免丢失参数
