该用pushState()实现页面内导航（如/list→/detail/123），用replaceState()修正URL或更新状态而不增加历史记录（如提交后清除查询参数）；二者均不触发popstate事件，且event.state仅含显式传入的状态对象，首次加载为null，不可用于权限校验；URL变更后刷新404需服务端配置兜底返回index.html，并设置正确的base href。
JavaScript 实现浏览器历史管理，核心是 History API，不是靠 location.href 刷新或 window.open 模拟，而是用 pushState()、replaceState() 和监听 popstate 事件——否则无法真正控制前进/后退行为，且 URL 变化不会触发页面重载。
什么时候该用 pushState() 而不是 replaceState()？
两者都修改 URL 并把状态对象存入历史栈，但关键区别在于是否新增一条历史记录：
-
pushState()：在当前条目后插入新条目，用户点「后退」会回到上一个 URL（适合页面内导航，如从 /list 切到 /detail/123） -
replaceState()：替换当前条目，不增加历史长度（适合修正 URL 或更新状态而不留回退入口，比如表单提交后清除查询参数） - 注意：
pushState()和replaceState()不会触发popstate事件，只有用户手动点前进/后退或调用history.back()等才会触发
popstate 事件里拿不到完整的导航上下文？
是的。 popstate 的事件对象 event.state 只包含你传给 pushState() 或 replaceSta 的第一个参数（即 state 对象），不包含 URL、HTTP 方法、请求头等任何其他信息。常见误区是以为能从中读出“是从哪个页面跳来的”：
- 必须自己在
pushState({from: 'list'}, '', '/detail/123')中显式存字段 -
event.state在页面首次加载时为null（即使 URL 有 hash 或 search），不要假设它一定存在 - 不能依赖
event.state做权限判断或数据拉取——它可被 JS 任意篡改，服务端校验不可少
为什么调用 pushState() 后 URL 改了，但刷新页面 404？
因为 pushState() 只改浏览器地址栏和历史栈，不向服务器发请求；而刷新时浏览器会真实发起 GET 请求，如果服务端没配置对应路由，就返回 404。这不是前端代码问题，而是前后端协作缺失：
- 前端路由（如 React Router、Vue Router）只在客户端生效，服务端必须兜底：所有非静态资源路径都返回
index.html - Nginx 示例配置：
location / { try_files $uri $uri/ /index.html; } - 注意：HTML 文件本身要设置
History API 表面简单，真正难的是状态一致性——URL、DOM、内存变量、服务端 session 四者必须对得上；最容易漏的是用户直接输入 URL 访问时，前端要能从 URL 解析出完整状态并还原界面，而不是只依赖 popstate 里的 state。
