核心区别在于是否新增浏览器历史记录条目：pushState 添加新记录，replaceState 替换当前记录；两者均不触发页面刷新，仅更新URL和state，且需同源。
pushState 和 replaceState 有什么区别？
核心区别在于是否新增浏览器历史记录条目：pushState 会往历史栈里加一条新记录，用户点后退能回到上一页；replaceState 则是直接替换当前记录，不增加长度，适合更新 URL 但不想让用户退回当前页的场景（比如筛选条件变化但不希望产生多余历史）。
两个方法签名一致：history.pushState(state, title, url)，其中 title 参数目前所有主流浏览器都忽略，传空字符串或 null 即可；state 是任意可序列化的 JS 值（如对象），它会被存入历史记录，后续通过 popstate 事件读取；url 必须同源，不能跨域，且不会触发页面跳转或重新加载。
常见错误：传入绝对路径却跨域，或传了相对路径但没注意当前 URL 的 base；例如当前页是 https://a.com/app/list，想跳到详情页，用 pushState({}, '', 'detail/123') 是合法的（解析为 https://a.com/app/detail/123），但用 pushState({}, '', '/detail/123') 就会变成 https://a.com/detail/123 —— 如果该路径不存在或跨子目录，可能破坏路由逻辑。
popstate 事件什么时候触发？
popstate 只在用户主动操作浏览器前进/后退按钮，或调用 history.back()、history.forward()、history.go(n) 时触发，**不会**因 pushState 或 replaceState 调用而触发。这点常被误以为“只要改了 history 就会 pop”，结果监听了却收不到事件。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 必须在页面初始化时就绑定监听，否则可能错过首次后退（比如从外链进入单页应用后立即后退）
-
event.state是你之前传给pushState或replaceState的那个state对象，不是当前 URL 解析结果 - 如果用
replaceState替换了当前记录，再点后退，触发的popstate拿到的是上一条记录的state，不是刚 replace 的那个
window.addEventListener('popstate', (event) => {
console.log('state:', event.state); // 例如 { page: 'detail', id: 123 }
renderPage(event.state);
});怎么安全地修改 URL 又不触发页面刷新？
仅靠 pushState / replaceState 不足以让浏览器地址栏实时反映变化——它们本身不改变 URL 显示，但配合合法的 url 参数，浏览器会自动更新地址栏（前提是同源）。关键约束有三个：
-
url必须与当前页面同源（协议 + 域名 + 端口），否则抛出SecurityError -
url可以是相对路径（推荐），也可以是完整同源 URL；但不能是纯 hash（#xxx）或带不同 origin 的绝对路径 - 如果只改 hash（如
/list#tab=2），应该用location.hash = 'tab=2'，而不是 History API —— 否则会多一条无意义的历史记录
典型陷阱：在 React/Vue 等框架中手动调用 pushState 后，没同步更新组件内部路由状态，导致视图和 URL 不一致；正确做法是先更新路由状态（比如设置 currentPath），再调用 pushState 更新浏览器地址栏。
History API 在 SPA 中容易漏掉什么？
最常被忽略的是服务端配置：当用户直接访问 https://example.com/dashboard/user/123（一个由前端路由控制的路径），如果服务端没做 fallback（比如 Nginx 返回 index.html 而不是 404），就会报错。这不是 History API 的问题，但它是启用它的前提。
另一个隐形坑是：调用 pushState 后，document.title 不会自动更新。虽然 API 有 title 参数，但浏览器不使用它。必须手动设：document.title = '用户详情 - 示例站';
还有兼容性注意点：IE10+ 支持，但 IE11 对 state 对象深度序列化支持较弱，避免传含函数、undefined 或循环引用的对象；现代项目基本不用考虑，但维护老系统时得留心。
