pushState不会触发页面刷新，因为它仅修改地址栏和历史栈而不发起导航请求，需手动更新DOM；其状态对象存于history.state，popstate事件仅在前进/后退时触发且须提前绑定监听。
pushState 为什么不会触发页面刷新
因为 pushState 只修改浏览器地址栏和历史栈，不主动发起导航请求。它常用于单页应用（SPA）中模拟“跳转”，但你得自己更新 DOM 或路由视图，否则 URL 变了页面内容却没变。
常见错误是只调用 pushState 却忘了同步渲染对应内容，导致用户点后退时 URL 回退了，但页面还是旧状态。
-
pushState第一个参数是任意可序列化的状态对象（比如{page: "detail", id: 123}），会被存入历史记录，后续popstate事件中可读取 - 第二个参数目前大多数浏览器忽略，传空字符串即可：
"" - 第三个参数是新 URL，必须同源；跨域会直接抛出
SecurityError - 该操作不会触发
hashchange或load，只会在用户前进/后退时触发popstate
popstate 事件监听要放在哪里
必须在页面加载完成后绑定，且不能依赖 DOM 就绪时机过晚——比如在某个按钮点击后才加监听，会导致首次后退失效。最稳妥的位置是脚本顶层或 DOMContentLoaded 回调里。
注意：popstate 在页面首次加载时**不会触发**（哪怕 URL 带有 state），只在用户通过浏览器前进/后退按钮、或 JS 调用 history.back() 等导航行为后触发。
立即学习“Java免费学习笔记（深入）”；
- 事件对象的
event.state就是之前pushState或replaceState传入的状态对象 - 不要在
popstate里直接调用pushState，否则容易陷入无限循环（尤其配合自动路由同步时） - 如果用 React/Vue，确保事件处理器能访问到当前组件状态，避免闭包捕获过期的 props 或 state
replaceState 和 pushState 的关键区别
replaceState 不新增历史记录项，而是替换当前项；pushState 则追加一条。这意味着：用 replaceState 改 URL 后点后退，会回到上一个真实页面，而不是刚 replace 的那个。
典型使用场景：replaceState 适合修正当前 URL（比如去掉冗余 query 参数、补全 hash）、或表单提交后清理地址栏；pushState 才是实现“前进/后退可逆”的基础。
- 两者参数完全一致，仅行为不同
- 都受同源限制，路径部分不能跨协议、域名、端口
- 如果想让后退跳过某次状态变更，用
replaceState；想支持回退到这个状态，必须用pushState
history.state 读取的是当前项，不是上一项
history.state 返回的是当前激活的历史记录项的状态对象，不是上一次的。它在页面加载后即存在（可能为 null），也随每次 pushState/replaceState 更新。
别误以为它能帮你“预判”后退目标——它只是快照，不是队列。真正需要感知导航方向（前进 or 后退），只能靠 popstate + 自己维护一个序号或时间戳字段。
- 首次打开页面时，
history.state通常为null，除非服务器返回的 HTML 中有<script>history.replaceState(...)</script> - 它不可写，只能通过
pushState/replaceState间接更新 - 调试时可在控制台直接输入
history.state查看当前状态，比翻 event 对象更快
popstate 触发时机的特殊处理（比如某些版本在页面未完全加载完时后退，事件可能丢失）。 
