history.pushState 不触发刷新但更新 URL 并存状态，state 存可序列化数据供 popstate 读取，url 需同源且不发起请求；popstate 仅用户导航时触发，replaceState 替换当前记录而非新增。
history.pushState 不会触发页面刷新，但能改变 URL 并把状态存进浏览器历史栈——这是实现无刷新路由、前进后退保留状态的核心机制。
pushState 的三个参数分别控制什么
pushState 接收三个参数：state、title、url。其中 title 在现代浏览器中被忽略（传空字符串或 null 即可），真正关键的是：
-
state：任意可序列化的 JS 值（对象、字符串、数字），会被存入历史记录，后续通过popstate事件读取；不能是函数或 DOM 节点 -
url：必须是同源的相对路径或绝对路径；浏览器地址栏会更新，但不会发起新请求；如果传了跨域 URL，会直接抛出SecurityError
示例：history.pushState({page: 'detail', id: 123}, '', '/item/123') —— URL 变为 /item/123，状态对象可被后续 popstate 捕获。
popstate 事件只在用户点击前进/后退时触发
popstate 不会在 pushState 或 replaceState 调用后立即触发，仅响应用户主动导航（如点击浏览器返回按钮、调用 history.back()）。
立即学习“Java免费学习笔记（深入）”；
- 监听写法必须用
window.addEventListener('popstate', handler)，而非onpopstate属性（后者不推荐且兼容性差） - 事件对象的
event.state就是之前pushState传入的state对象；首次加载页面时该值为null - 注意：服务端未配置 fallback 时，用户直接访问
/item/123会 404——这和前端路由无关，是部署问题
pushState 和 replaceState 的关键区别
两者 API 完全一致，但行为不同：
-
pushState：在历史栈**末尾新增一条记录**，用户可点击「后退」回到上一页 -
replaceState：**替换当前历史记录项**，不增加新条目，适合修正 URL（如从/search?q=foo改为/search?q=bar）而不留冗余记录 - 误用
pushState替代replaceState会导致历史栈膨胀，用户狂点后退可能卡在一堆相似 URL 上
常见场景：表单提交成功后跳转详情页，用 pushState；搜索关键词变化但不想让用户退回旧关键词页，用 replaceState。
手动触发 popstate 无法模拟真实导航
不能靠 window.dispatchEvent(new Event('popstate')) 来“假装”用户点了后退——这不会改变 URL，也不会影响历史栈位置，event.state 也会是 undefined。
- 测试
popstate行为，必须真实调用history.back()、history.forward()或点击浏览器按钮 - 若需程序化导航并触发状态更新，应组合使用：
history.pushState(...)→ 手动更新视图 → 再监听后续popstate做反向同步 - SPA 中常配合
location.pathname和event.state做双重校验，避免因 state 丢失导致状态错乱
真正容易被忽略的是：URL 变更和状态变更不是原子操作——pushState 改 URL 成功，不代表 popstate 一定能拿到对应 state；比如页面重载后，state 会丢失，只能靠解析 URL 恢复。
