pushState在历史栈新增记录，replaceState直接替换当前记录；两者参数均为(state, title, url)，其中state为可序列化数据，title被忽略，url须同源；仅浏览器导航触发popstate事件，需手动监听并初始化渲染。
pushState 和 replaceState 的核心区别是什么
两者都用于修改浏览器地址栏 URL 且不触发页面刷新，但 pushState 会在历史栈中新增一条记录，用户点「后退」会回到上一个状态；replaceState 则直接替换当前历史记录，后退时跳过这一步。
这个差异直接影响用户导航体验和 SPA 路由实现逻辑。比如表单提交后跳转详情页，用 pushState 更合理；而页面初始化时修正 URL（如去掉 hash 或补全 query），应优先用 replaceState，避免栈里堆一堆无意义的初始状态。
调用 pushState/replaceState 的三个参数怎么填
两个方法签名完全一致：history.pushState(state, title, url) 和 history.replaceState(state, title, url)。其中：
-
state：任意可序列化的 JS 值（对象、字符串、数字），会被存入历史记录，后续通过popstate事件读取。不要传函数或 DOM 节点。 -
title：目前所有主流浏览器都忽略该参数，可传空字符串""或null，无需纠结。 -
url：必须是同源的相对路径或绝对 URL。不能跨域，也不能是纯片段（如#section1），否则抛错SecurityError。
常见错误：传入 "#abc" 导致报错；传入 "https://other.com/path" 触发跨域拒绝；传入 undefined 或 null 造成 URL 变为空白页。
如何监听 URL 变化并同步更新页面
仅调用 pushState 或 replaceState 不会触发 hashchange 或 popstate，只有用户手动点击「前进/后退」按钮、调用 history.back() 等导致历史栈指针移动时，才会派发 popstate 事件。
必须主动监听并处理：
window.addEventListener('popstate', (event) => {
const state = event.state; // 就是 pushState 传入的那个 state 对象
if (state && state.page === 'detail') {
renderDetailPage(state.id);
}
});
注意点：
- 首次加载页面时不会触发
popstate，需在 JS 初始化时手动读取window.location并渲染对应视图。 -
replaceState不会触发popstate—— 它只是替换当前项，没发生“栈指针移动”。 - 不要在
popstate处理器里再调用pushState，容易陷入循环（尤其配合路由库时）。
实际使用中容易被忽略的兼容性和边界问题
IE10+ 支持 pushState/replaceState，但 Android 4.0–4.3 的 WebView 存在 bug：调用后 location.href 不实时更新，需用 document.URL 或 location.toString() 获取最新值。
更隐蔽的问题是 SEO 和服务端 fallback：
- 搜索引擎爬虫通常不执行 JS，所以纯前端 history 模式下，
/user/123这样的 URL 若服务端没配置通配路由返回同一份 HTML，就会 404。 - 用户直接访问
/post/edit，如果服务端没做 fallback，就无法加载应用，自然也触发不了 JS 中的路由匹配逻辑。 -
state对象大小受限（Chrome 约 6MB，Firefox 更小），别往里面塞大数组或 base64 图片。
真正难的不是调用那行代码，而是确保每次 URL 变化都有对应的状态还原能力，并让服务端和客户端对“同一 URL 应展示什么”达成一致。
