pushState 在历史栈中新增一条记录，replaceState 用新状态覆盖当前记录；两者均不刷新页面、仅同源生效，且第三个参数 title 被多数浏览器忽略。
JavaScript 不能随意删除或清空浏览器历史记录，History API 只允许在当前 tab 的会话中**前进、后退、替换或添加一条记录**，且无法读取其他页面的 URL 或跳转到非同源历史项。
pushState 和 replaceState 的核心区别是什么
pushState 在历史栈中新增一条记录，用户点击返回按钮会回到上一条；replaceState 则是用新状态覆盖当前记录，不增加栈长度。
- 两者都不触发页面刷新，但都会改变地址栏 URL（需同源）
-
pushState适合“进入新视图”，比如单页应用中打开详情页；replaceState适合“修正当前状态”，比如表单提交后清除查询参数但不希望用户退回空参页 - 两个方法第三个参数
title在多数浏览器中被忽略，不要依赖它做逻辑判断 - 第二个参数（
state对象）会被序列化存入历史记录，可用于popstate事件中还原界面状态
popstate 事件什么时候触发
仅当用户点击浏览器「后退」或「前进」按钮，或调用 history.back()、history.forward()、history.go() 时触发 —— 不会 因 pushState/replaceState 调用而触发。
- 监听必须写在页面加载后立即注册，否则可能错过首次 popstate（如页面从 history 恢复时）
- 事件对象的
event.state是之前传入pushState或replaceState的 state 对象的副本，不是引用 - 若未通过
pushState设置过 state，event.state为null，需判空
如何安全地实现“返回上一页但不离开当前域名”
不能依赖 history.back()，因为用户可能从外站跳入，直接后退会跳出当前站点。更稳妥的做法是：先检查 document.referrer 是否同源，再决定是否用 history.back()，否则降级为 location.href = '/' 或指定路径。
立即学习“Java免费学习笔记（深入）”；
-
document.referrer不可靠（可能为空或被屏蔽），仅作参考 - 更健壮的方式是：在每次
pushState时手动维护一个轻量级的路由栈（如数组），由 JS 控制“逻辑后退” - 避免在
popstate中嵌套调用pushState，容易引发循环触发
常见兼容性与风险点
History API 在 IE10+ 和所有现代浏览器中可用，但部分旧安卓 WebView（如 Android 4.3 及更早）对 state 对象大小有限制（约 640KB），超限会导致 pushState 静默失败。
- 不要往
state里塞 DOM 节点、函数或循环引用对象，序列化会出错 - URL 改变后，服务端仍需能响应该路径（如部署在子路径下，需配置服务器 fallback 到 index.html）
- SPA 中使用前务必确认路由库（如 React Router、Vue Router）已接管 history，否则自行操作可能与库冲突
真正难的不是调用那几行代码，而是把 state 设计成可序列化、可预测、可回溯的数据结构，并在 popstate 触发时准确还原 UI —— 这部分逻辑一旦松散，就很难调试。
