最可靠检测方式是 if (window.history && typeof window.history.pushState === 'function')，需避免用 in 操作符或仅判断 history 存在；pushState 后 history.state 和 history.length 可验证状态写入，但受隐私模式等影响；刷新 404 是服务端路由未配置 fallback 导致。
怎么检测浏览器是否支持 history.pushState
直接检查 window.history 对象是否存在 pushState 方法即可，这是最轻量、最可靠的运行时判断方式。注意不能只靠 typeof history !== 'undefined'，因为旧版 IE（如 IE9）虽有 history 对象，但没有 pushState。
if (window.history && typeof window.history.pushState === 'function') {
// 支持 HTML5 History API
} else {
// 降级处理，例如用 hashchange 或整页跳转
}
- 不要用
in操作符（如'pushState' in history），在某些 Android 4.x WebView 中会误报为true，但实际调用抛错 - 避免在页面加载早期就执行该检测——确保
window和history已就绪（通常 DOMContentLoaded 后是安全的） - 服务端无法直接检测该能力，需依赖客户端上报或 UA 特征推测（不推荐，UA 不可靠）
pushState 调用后如何确认状态已写入历史栈
HTML5 History API 是同步写入的，pushState 返回后，history.length 应增加 1，且 history.state 应等于你传入的 state 参数（注意：仅当前项，不是整个栈）。
const state = { page: 'detail', id: 123 };
history.pushState(state, '', '/item/123');
console.log(history.state); // { page: 'detail', id: 123 }
console.log(history.length); // 比调用前多 1
-
history.state只反映当前激活项的状态，不是“刚 push 的那个”——如果用户此时点了浏览器后退，再回来，state才会变回你刚设的值 - 不要依赖
history.length做逻辑分支，它在跨域 iframe、隐私模式（如 Safari 无痕）下可能不准或被限制 - 真正可靠的“确认”方式是监听
popstate并观察是否能捕获到对应state，但这属于后续行为验证，不是即时确认
为什么 pushState 后刷新页面会 404？怎么识别这是服务端缺失路由导致的
这不是前端能“识别”的特征，而是典型的服务端配置问题：pushState 只改了 URL 和历史记录，不触发请求；但刷新时浏览器向服务端发起真实 GET 请求，若服务端没配置 fallback（如将所有非静态资源路径返回 index.html），就会 404。
- 现象上可辅助判断：SPA 路由（如
/user/5）刷新 404，但根路径/正常，且网络面板中该请求状态码明确为404（而非前端拦截的假 404） - 不是 JS 报错，控制台无
pushState相关异常，说明前端执行成功 - 本地开发时常见于未启用
historyApiFallback: true（Webpack Dev Server）或 Vite 的server.historyApiFallback - 上线后需 Nginx 配置
try_files $uri $uri/ /index.html;类似规则
兼容性边界：哪些情况看似支持 pushState 实际不可靠
部分环境返回 typeof history.pushState === 'function'，但实际行为异常，需额外规避：
立即学习“前端免费学习笔记（深入）”；
- iOS 9.3 Safari：支持
pushState，但若state对象含函数、DOM 节点或循环引用，序列化失败且静默丢弃（history.state变为null） - Android pushState 后，
popstate事件不触发，或history.state为空 - Firefox 隐私模式：
pushState可调用，但history.length固定为 1，且后退按钮灰显——无法真实操作历史栈 - 所有浏览器：若目标 URL 协议/域名/端口与当前页不一致，
pushState会抛SecurityError异常（不是TypeError）
真正关键的不是“能否调用”，而是“能否稳定读写 state 并响应 popstate”。简单检测只能保底，复杂场景建议封装一层带 fallback 的路由控制器，并在关键路径做 try/catch + 状态快照比对。
