核心区别在于是否新增历史记录条目：pushState() 添加新记录，replaceState() 替换当前记录；两者参数均为(state, title, url)，title被忽略，url须同源，state为可序列化对象且建议≤640KB。
history.pushState() 和 history.replaceState() 的区别在哪
核心区别在于是否新增历史记录条目：pushState() 会在历史栈中添加一条新记录，用户点击后退按钮会回到上一个状态；replaceState() 则直接替换当前记录，不增加栈长度，适合更新 URL 但不想让用户回退到旧状态的场景（比如表单提交后刷新页面状态）。
两者参数完全一致，都是 (state, title, url)。注意：title 参数目前所有主流浏览器都忽略，传空字符串或 null 即可；url 必须同源，否则抛出 SecurityError；state 可以是任意可序列化的对象，它会被存入历史记录中，供 popstate 事件使用。
-
state对象大小建议控制在 640KB 以内，超出可能被截断（Chrome 行为） - URL 不需要真实存在，但必须符合同源策略 —— 例如当前页是
https://a.com/page，就不能 pushhttps://b.com/other - 调用后浏览器地址栏立即更新，但不会触发页面刷新或重新请求资源
监听 history 变化要用 popstate，不是 hashchange
popstate 是监听 pushState、replaceState 或浏览器前进/后退按钮触发的历史变化的唯一标准事件。它和 hashchange 完全无关 —— 后者只响应 # 片段标识符变化，且不携带 state 数据。
注意：页面首次加载时不会触发 popstate，即使 URL 带有 state；只有通过 JS 调用历史 API 或用户点击前进/后退才会触发。
立即学习“Java免费学习笔记（深入）”；
- 事件回调中通过
event.state获取 push/replace 时传入的状态对象 - 该事件无法区分是用户操作还是 JS 调用导致的，如需区分，需自行维护标志位
- 不要在
popstate回调里再调用pushState，否则容易陷入无限循环（尤其在未加 guard 的 SPA 路由中）
window.addEventListener('popstate', (event) => {
console.log('当前 state:', event.state);
if (event.state?.page === 'detail') {
renderDetail(event.state.id);
}
});
history.back() / forward() / go() 的实际行为限制
这三个方法看似简单，但受制于浏览器安全策略和历史栈状态。它们不会抛出异常，但可能“静默失败” —— 比如调用 history.back() 时已到历史栈底，页面不会跳转，也不会报错。
-
go(n)中n为 0 相当于刷新，但不会触发popstate事件 - 如果页面是通过
location.replace()打开的，它会从历史栈中移除前一条记录，影响back()行为 - iFrame 内的脚本无法操作父页面 history，反之亦然，跨域时连读取
history.length都会报错
SPA 路由中容易忽略的 scrollRestoration 问题
单页应用用 history API 切换视图时，浏览器默认会尝试滚动到上次位置（scrollRestoration: 'auto'），这在列表页 → 详情页 → 返回列表页场景下非常干扰体验 —— 用户可能突然被滚到页面中间。
解决方案是在首次进入应用时显式关闭：
if ('scrollRestoration' in window.history) {
window.history.scrollRestoration = 'manual';
}
之后你就可以自己控制滚动逻辑，比如返回列表页时 scrollTo(0, 0)，进详情页时保持原位置或定位到标题锚点。这个设置仅对当前页面生命周期有效，刷新后重置。
真正麻烦的是 iOS Safari —— 它对 scrollRestoration 支持不完整，有时仍会抢在 JS 执行前滚动，所以关键路径上还得加 setTimeout(() => scrollTo(...), 0) 做兜底。
