firefox无法直接禁用history.pushstate/replacestate，但可通过about:config将dom.history.pushstate.enabled和dom.history.replacestate.enabled设为false，或用ublock origin规则example.com##+js(set, history.pushstate, null)针对性拦截。
Firefox 里 history.pushState 和 replaceState 被滥用时怎么限制
Firefox 本身不提供开关直接禁用 history.pushState 或 replaceState，但可通过扩展或配置项大幅降低劫持风险。关键不是“阻止所有调用”，而是让恶意脚本无法静默篡改历史栈、伪造返回行为。
常见现象：点返回键没反应、反复跳回同一页面、地址栏 URL 突然变掉但页面内容不动——基本是站点在 popstate 监听中嵌套调用 pushState，制造假历史项。
- Firefox 115+ 默认启用
dom.pushState.enabled（不可关闭），但可配合dom.history.maxEntryCount控制缓存深度 - 真正有效的是禁用非同源脚本的
history写操作：在about:config中将dom.disable_window_open_feature.location设为true（影响较小，但能阻断部分重定向链） - 更彻底的做法是使用
user.js禁用history.replaceState的副作用：添加user_pref("dom.history.enabled", false);—— 注意这会破坏所有单页应用（SPA）的路由，仅建议临时排查用
推荐用 uBlock Origin + 自定义过滤规则防重定向死循环
uBlock Origin 的静态过滤能力比 Firefox 内置防护更精准，尤其对「监听 popstate 后立即 pushState」这类模式识别稳定。
在 uBlock Origin 的「我的过滤器」中添加以下规则：
example.com##+js(set, history.pushState, null) example.com##+js(set, history.replaceState, null)
说明：
- 只对特定域名生效（把
example.com换成目标站点），不影响其他网页 - 使用
+js(set, ...)是 uBO 的 JavaScript 注入规则，直接覆盖原生方法为null，比 CSS 隐藏或网络拦截更底层 - 若页面因此白屏或报错
TypeError: history.pushState is not a function，说明它强依赖该 API，此时应换用「重定向拦截」策略而非禁用 API
遇到无限重定向时如何快速中断并查看源头
Firefox 开发者工具里的网络面板（Network）默认不会记录 pushState 变化，但能抓到真实 HTTP 重定向（301/302/307）和 location.href 跳转。
操作步骤：
- 按
Ctrl+Shift+E打开网络面板，勾选「Preserve log」 - 复现问题后，在过滤栏输入
redirect，查看所有状态码含3xx的请求 - 右键某条重定向请求 → 「Copy → Copy as cURL」，粘贴到终端运行，确认是否服务端主动发起（排除前端 JS 劫持）
- 若无 3xx 请求，但地址栏持续变化：打开控制台（
Ctrl+Shift+K），执行history.length，正常网页一般 ≤ 50；若 > 200，基本可判定前端恶意堆栈
为什么不能靠禁用 JavaScript 彻底解决
禁用 JS（javascript.enabled = false）确实能杜绝所有历史劫持，但代价是多数现代网站无法使用，且 Firefox 已不再推荐此做法。
更现实的权衡点：
- 对高风险站点（如短链接跳转页、未备案推广页），用
Temporary Containers插件隔离会话，避免跨页 history 共享 - Firefox 的
privacy.spoof_english设为true可减少基于 UA 的定向劫持，虽不直接防返回按钮，但常与重定向攻击共存 - 真正难处理的是 Service Worker 拦截
fetch后伪造响应并调用history.replaceState——这种需检查about:debugging#/runtime/this-firefox中注册的 SW，并手动 unregister
历史栈劫持的隐蔽性在于它不触发网络请求，也不报错，只有用户点击返回时才暴露。盯住 history.length 和地址栏变化节奏，比等错误提示更早发现问题。
