应根据是否需保留返回入口选择：pushState用于导航跳转（如页面切换），新增历史记录；replaceState用于URL微调（如参数更新），替换当前记录不增加栈长。
history.pushState 和 history.replaceState 怎么选
浏览器历史记录不是靠“读取”实现的，而是靠主动“写入”和“管理”。history.pushState 会新增一条历史记录，用户点后退能回到上一个状态；history.replaceState 则是替换当前条目，不增加长度，适合更新 URL 但不想让用户退回同一页面的不同参数态（比如筛选条件变化但不希望堆满历史栈）。
常见错误：用 pushState 处理表单提交后的跳转，结果用户狂点后退，反复触发相同逻辑。应该先判断是否已有对应状态，或改用 replaceState 避免冗余。
- 路由类场景（如 SPA 页面切换）——优先
pushState - URL 参数微调（如分页、排序、搜索关键词）——优先
replaceState - 两者第一个参数都是 state 对象，必须是可序列化的，不能传函数或 DOM 节点
- state 对象大小有浏览器限制（Chrome 约 640KB），超限会静默失败，不报错
监听 popstate 事件时为什么没触发
popstate 只在用户点击前进/后退按钮、或调用 history.back()/history.forward() 时触发，**不会**因 pushState/replaceState 调用而触发。这是最常被误解的一点。
另一个坑：页面首次加载时，即使 URL 带有 state，也不会触发 popstate。得手动检查 history.state 并初始化视图。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 必须在
window上监听，不是document或某个元素 - 事件回调里拿不到原始 URL，要用
location.href或location.pathname + location.search - 如果用 React/Vue 等框架，注意组件卸载时移除监听，否则可能造成内存泄漏
history.length 不是真实历史条数
history.length 返回的是“会话历史堆栈中元素个数”，但它受 iframe、跨域页面、隐私模式等影响，**不可靠**，也不反映用户实际访问过的页面数。Chrome 隐私模式下它恒为 1；某些 iOS WebView 中甚至始终返回 0。
别拿它做“能否后退”的判断依据。真要控制按钮状态，应该自己维护一个布尔值，比如：
let canGoBack = false;
window.addEventListener('popstate', () => {
canGoBack = true; // 至少触发过一次才认为可回退
});
// 初始化时也可从 history.state 是否为空判断
if (history.state !== null) canGoBack = true;
-
history.length是只读属性，无法修改 - 它包含所有同源页面跳转，也包括
file://协议下的本地文件（但现代浏览器大多禁用） - 想模拟“历史列表”？只能自己用数组存
pushState时的路径+state，别指望浏览器暴露完整记录
服务端如何配合前端 history 模式
SPA 用 pushState 跳转到 /user/123 后，如果用户刷新页面，请求会直接打到服务端——而服务端根本不知道这个路径是前端路由，大概率返回 404。
解决方法不是让前端“读历史”，而是让服务端兜底：所有非 API、非静态资源的请求，都返回 index.html，交由前端路由接管。
- Nginx 配置示例：
try_files $uri $uri/ /index.html; - Express 中间件：
app.get('*', (req, res) => res.sendFile(path.join(__dirname, 'index.html'))); - Vite / Webpack Dev Server 默认已开启
historyApiFallback，但构建部署后仍需服务端配合 - 注意：API 请求路径（如
/api/users）必须排除在外，否则接口请求也会被重定向
真正的历史记录功能从来不是靠“列出过去访问了哪些 URL”实现的，而是靠你对 state 的设计、对导航时机的控制、以及服务端和前端之间那条隐性的契约。漏掉任意一环，用户点一下后退，页面就白了。
