火狐卡死因js阻塞或扩展冲突，应调低dom.max_script_run_time至3、禁用硬件加速、停用flash、用无痕窗口验证并二分法排查翻译类扩展。
火狐浏览器打开网页时突然卡住、鼠标点击无反应、滚动条冻结、地址栏输入延迟，且反复弹出“警告：无响应脚本”对话框，说明 JavaScript 执行已陷入阻塞或死循环，但问题未必出在网页本身——可能是浏览器配置阈值过高、GPU 渲染冲突、Flash 插件残留或扩展注入脚本互相干扰。
缩短脚本超时阈值
火狐默认等待 10 秒才中断脚本，但很多现代网页在低端设备或旧驱动下，3 秒就已卡死主线程。拖长等待只会锁死整个 UI，无法操作也无法关闭标签页。
在地址栏输入 about:config → 回车 → 点击“我保证会小心”。
在搜索框中输入 dom.max_script_run_time → 双击该项 → 将数值从 10 改为 【3】。
关闭所有火狐窗口后重启。此后脚本连续运行满 3 秒无响应，就会立即弹窗，你可果断点“停止脚本”，避免界面彻底僵死。
禁用硬件加速释放 GPU 线程
当显卡驱动与 Firefox 的 WebRender 渲染引擎不兼容时，GPU 线程会在脚本绘制阶段卡死，表现为“脚本仍在运行”，实则是图形管线死锁——此时 CPU 占用可能很低，但页面完全无响应。
菜单 → 设置 → 左侧选“常规” → 滚动到“性能”区域。
取消勾选“使用推荐的性能设置” → 再取消勾选“使用硬件加速”。
【必须重启浏览器才能生效】。这一步对搭载 Intel HD Graphics 4000/5000 或 AMD Radeon R5/R7（2013–2015 年型号）的老机器效果最明显。
停用 Flash 插件防止静默阻塞
尽管 Flash 已淘汰，但部分内网系统、旧教育平台或本地 HTML 文件仍依赖它。启用沙箱保护模式后，Flash 会在加载动画帧时触发安全检查，极易造成主线程阻塞，且不报错、不弹窗，只表现为整个标签页静默假死。
方法一：菜单 → 附加组件 → 左侧选“插件” → 右侧找到 “Shockwave Flash” → 下拉菜单改为“询问是否激活”。
方法二（更彻底）：地址栏输入 about:config → 搜索 dom.ipc.plugins.flash.disable-protected-mode → 右键切换为 true。
注意：修改后需关闭所有火狐窗口再重开，否则 Flash 进程可能残留并继续干扰。
用无痕窗口快速验证是否为扩展冲突
无痕模式默认禁用全部扩展、不读取本地存储、不加载用户脚本，是验证是否由扩展引发问题的黄金标准。
第一步：按 Ctrl + Shift + P 新建无痕窗口 → 直接访问出问题的网页。
第二步：观察排版、交互、控制台报错是否回归正常。
第三步：若无痕中一切正常，说明问题 100% 来自常规配置下的扩展组合；若仍异常，则需转向 JS/CSS/缓存等底层问题排查，无需继续本流程。
精准定位翻译类扩展冲突
当卡死现象集中出现在含多语言内容的页面（如英文维基百科、技术文档），极可能是多个翻译类扩展（如“沙拉查词”“Mate Translate”“Immersive Translate”）同时注入脚本、重复绑定事件监听器或竞争 DOM 操作权限所致。
直接在地址栏输入 about:addons → 点击左侧“扩展” → 扫描名称含“translate”“词典”“查词”“双语”的项目 → 勾选全部 → 点击右上角“…” → 选择“禁用”。
禁用后刷新原网页，若点击立即恢复响应，说明问题确由这些扩展共同引发。
用二分法快速定位冲突组合：
① 将所有翻译扩展分为 A/B 两组（如 A 组：沙拉查词、DeepL Web Translate；B 组：Mate Translate、Immersive Translate）。
② 仅启用 A 组，访问卡死网页并操作 1 分钟；若未卡死，再启用 B 组中的第一个扩展测试；若此时卡死，则 B 组首个即为关键冲突源。
③ 若 A 组启用即卡死，说明冲突存在于 A 组内部。将 A 组再拆为两个单扩展子集，重复启用测试——此法最多 3 轮即可从 6 个扩展中锁定具体冲突对。
注意：测试期间务必关闭“HTTPS-Only 模式”（设置 → 隐私与安全 → HTTPS-Only 模式 → 关），否则部分翻译扩展会因强制升级请求协议而反复重试连接，伪装成卡死现象。
