history.pushState()不触发页面刷新，因它仅修改URL和历史栈而不发起新导航请求，适用于SPA无刷新路由；其state参数为可序列化对象，title参数多数浏览器忽略，url须同源；popstate仅在用户后退/前进或调用back()/forward()时触发，且需尽早绑定监听。
JavaScript 的 history API 能直接操作浏览器地址栏和历史栈，但不能读取完整历史列表（出于隐私限制），也不能跳转到用户未访问过的任意 URL —— 只能前进、后退，或用 pushState/replaceState 修改当前条目或添加新条目。
为什么 history.pushState() 不触发页面刷新？
它只修改 URL 和历史栈，不发起新导航请求。适合单页应用（SPA）实现无刷新路由切换。
- 第一个参数
state是任意可序列化的对象，会随该历史条目保存，在popstate事件中可用 - 第二个参数
title当前大多数浏览器忽略，传空字符串''即可 - 第三个参数
url必须是同源的相对路径或绝对路径；跨域会抛出SecurityError - 调用后，
location.href立即更新，但 DOM 不变，需手动更新内容
history.pushState({ page: 'about' }, '', '/about');
popstate 事件什么时候触发？
仅当用户点击浏览器「后退」或「前进」按钮，或调用 history.back()/history.forward() 时触发；pushState 和 replaceState 不会触发它。
- 事件对象的
state属性就是对应历史条目中保存的state对象（可能为null） - 必须在页面加载后尽早绑定，否则可能错过首次导航（如用户从外部链接带状态进入）
- 注意：页面初始加载不会触发
popstate，哪怕 URL 带有状态
window.addEventListener('popstate', (event) => {
console.log('返回/前进到了 state:', event.state);
if (event.state?.page === 'about') {
loadPage('about');
}
});
history.replaceState() 和 pushState() 的关键区别
前者替换当前历史条目，后者新增一条；两者都不刷新页面，但对「后退」行为影响不同。
- 用
replaceState修改当前 URL 后，按一次「后退」会回到上一个真实访问过的页面，而不是当前这个被替换的条目 - 适合修正 URL（如移除 hash、补全 query 参数），或避免用户误点后退回到一个中间无效状态
- 如果在
popstate处理中又调用了replaceState，要小心别陷入无限循环（例如状态没变却反复重写）
// 当前 URL 是 /search?q=js，想改成 /search?q=javascript 且不增加历史长度
history.replaceState({ q: 'javascript' }, '', 
'/search?q=javascript');
'/search?q=javascript');容易被忽略的兼容性和边界问题
history.state 在页面刚加载时是 null，即使 URL 是通过 pushState 进来的；只有触发过一次 popstate 后，它才反映当前条目的 state。
- Android WebView 和旧版 iOS Safari 对
state对象大小有限制（通常 ≤ 640KB），超限会静默失败 -
history.go(n)中n超出历史栈范围时，不会报错，只是无效果 - 服务端必须能响应所有前端生成的 URL（比如
/dashboard/stats），否则用户刷新页面会 404 —— 这不是 JS 能解决的
