火狐浏览器加载多语言网页卡死极可能是多个翻译类扩展冲突所致，需先禁用所有翻译扩展验证，再用二分法定位冲突组合，并通过无痕窗口和事件监听器检查确认具体冲突源。
当火狐浏览器在加载网页时突然卡死、点击无响应，且该现象集中出现在含多语言内容的页面（如外文新闻、技术文档），极可能是多个翻译类扩展（如“沙拉查词”“Mate Translate”“Immersive Translate”）同时注入脚本、重复绑定事件监听器或竞争DOM操作权限所致。
确认是否为翻译类扩展引发的卡死
这一步必须先做，避免误判为网络或硬件问题。打开一个已知会卡死的外文网页（例如英文维基百科某条目），保持页面静止5秒后尝试点击任意链接——若完全无反应，立即按 Esc 键中断可能正在执行的阻塞脚本；若仍无效，右键→“检查元素”→切换到“控制台（Console）”面板，观察是否有大量重复报错（如 TypeError: Cannot read property 'addEventListener' of null 或 Maximum call stack size exceeded）。出现这类错误，基本可锁定是翻译插件脚本互相覆盖或递归调用导致的主线程冻结。
直接在地址栏输入 about:addons → 点击左侧“扩展” → 扫描名称含“translate”“词典”“查词”“双语”的项目，勾选全部，点击右上角“…”，选择“禁用”。
禁用后刷新原网页，若点击立即恢复响应，说明问题确由这些扩展共同引发。
用二分法快速定位冲突组合
翻译类扩展常存在隐性兼容问题：单独启用都正常，两两组合却必现卡死。逐个启用效率低，改用二分法压缩排查轮次。
第一步：在 about:addons 中，将所有翻译扩展分为A/B两组（如A组：沙拉查词、DeepL Web Translate；B组：Mate Translate、Immersive Translate）。
第二步：仅启用A组，访问卡死网页并操作1分钟；若未卡死，再启用B组中的第一个扩展，测试；若此时卡死，则B组首个即为关键冲突源。
第三步：若A组启用即卡死，说明冲突存在于A组内部。将A组再拆为两个单扩展子集，重复启用测试——此法最多3轮即可从6个扩展中锁定具体冲突对。
注意：测试期间务必关闭“HTTPS-Only模式”（设置→隐私与安全→HTTPS-Only模式→关），否则部分翻译扩展会因强制升级请求协议而反复重试连接，伪装成卡死现象。
隔离验证：无痕窗口 + 手动启用单个扩展
无痕窗口默认不加载未勾选“允许在私密窗口中运行”的扩展，是天然的干净对照环境。
按 Ctrl + Shift + P（Windows/Linux）或 Command + Shift + P（Mac）新建无痕窗口。
在无痕窗口中访问同一卡死网页，确认操作完全流畅——这证明问题不在网页本身或火狐核心。
回到普通窗口，在 about:addons 中，只启用你怀疑最深的那一个翻译扩展（其余全部禁用），重启浏览器后再测试。若卡死重现，【该扩展即为不可替代的冲突源，需卸载或降级】。
这一步能排除“多个扩展共存才触发”的假象，直击根本问题组件。
检查扩展注入脚本是否劫持事件监听器
方法一：在卡死页面按 F12 打开开发者工具 → 切换到“检查器（Inspector）” → 右键任一可点击元素（如导航链接）→ 选择“检查元素” → 在右侧“元素”面板中右键该HTML节点 → 选择“查看监听器（Event Listeners）”。展开 click 分支，观察是否存在多个来源（如 content_script.js、inject.js、translator.js）重复绑定，且其中至少一个监听器指向已失效的闭包函数（显示为 function () { [native code] } 或路径异常）。若有，说明脚本已污染事件链。
方法二：在控制台（Console）中粘贴执行：getEventListeners(document).click?.map(l => l.listener.toString().slice(0,80))，回车。若返回多个含 translate、word、popup 字样的匿名函数，证实多翻译脚本正同时监听全局点击事件，极易因执行顺序错乱导致阻塞。
此时不要手动删除监听器——扩展会自动重绑。唯一有效动作是卸载其中至少一个。
