window.history.length 只反映当前会话 history stack 的状态数，非真实访问页数；仅 pushState 会增加，普通跳转、刷新、新标签页均保持为1，SPA中需主动管理才具参考价值。
为什么 window.history.length 几乎总是返回 1 或 2？
它不反映你「真实访问过的网页数量」，而是当前会话中 history stack 的状态数。每次调用 history.pushState() 或 history.replaceState() 才会增加该值；普通页面跳转（如点击链接、location.href =）在多数浏览器中**不会增加** window.history.length，尤其在单页应用（SPA）中更明显。
常见错误现象：window.history.length 在新打开的标签页里是 1，在刷新后还是 1，点几次链接也几乎不变——这不是 bug，是规范行为。
- Chrome/Firefox/Safari 对初始页面都设为
length === 1 - 调用
history.pushState({},"","/new")后，length变为 2 -
history.replaceState()不改变length - 跨域 iframe 或 sandbox 页面无法读取主窗口 history 长度
哪些场景下 window.history.length 有实际参考价值？
仅适用于你主动管理 history 的 SPA 场景，比如 React Router 或 Vue Router 启用了 createBrowserHistory 并且未禁用 usePushState。此时你可以用它粗略判断用户是否至少「前进过一次」。
但要注意：这个值不能用于「禁止后退」或「统计 PV」——它既不可靠也不可跨会话持久化。
立即学习“前端免费学习笔记（深入）”；
- 适合做：「当前是不是首页？」的辅助判断（如
history.length 时隐藏「返回」按钮） - 不适合做：用户行为分析、路由埋点、权限拦截（
popstate才是响应后退的正确钩子） - 移动端 WebView 中该值可能被裁剪或固定为 1（如某些微信内置浏览器）
history.length 和 performance.navigation.type 混用会出什么问题？
这两个 API 完全无关：performance.navigation.type（已废弃）只表示当前页面如何加载（0=导航、1=重载、2=后退、3=前进），而 history.length 是栈深度快照。强行关联会导致逻辑错乱。
例如你看到 history.length === 1 就认为用户是直接打开页面，但如果他刚从另一个 tab 切换回来，这个判断就失效了。
- 不要用
history.length === 1替代document.referrer === ""来判断首屏 - 不要监听
popstate事件时依赖history.length做分支（事件本身带state和触发类型） - 现代替代方案：用
performance.getEntriesByType("navigation")[0].type获取准确导航类型
有没有更靠谱的方式模拟「历史条目数」？
没有标准 API 能获取完整浏览历史（出于隐私限制，浏览器故意屏蔽）。如果你真需要计数，只能自己维护一个轻量 state 栈：
const historyStack = [location.href];
window.addEventListener("pushstate", () => {
historyStack.push(location.href);
});
window.addEventListener("replacestate", () => {
historyStack[historyStack.length - 1] = location.href;
});
// 注意：需配合 popstate + 自定义 back() 方法才能近似模拟
但这仅限同域内、可控路由的场景；一旦用户手动输入地址、关闭标签页、或使用浏览器前进/后退按钮，你的栈就和真实 history 不一致了。
真正容易被忽略的一点：哪怕你在本地开发时看到 history.length 变化正常，上线后在 iOS Safari 或旧版 Android WebView 中，它的行为可能完全不同——别把它当事实依据用。
