火狐浏览器加载多语言网页突然卡死？先别急着怪网络或硬件——极大概率是多个翻译类扩展在背后“打架”。

这类问题有个典型特征：卡死只发生在含外文内容的页面（比如英文维基、技术文档），而普通中文页面一切正常。

原因很简单，几个翻译插件（比如“沙拉查词”“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组

只启用A组，访问卡死页面，操作一分钟左右。如果没卡死，再启用B组里的第一个扩展，继续测试。如果此时卡死，说明B组第一个就是关键冲突源。

第三步：如果A组一启用就卡死

那冲突就在A组内部。把A组再拆成两个单扩展，重复测试。用这种方法，即使有6个扩展，最多3轮就能找出具体是哪两个插件在互掐。

注意：测试期间最好关闭“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] } 或路径异常）。有的话，说明脚本已经污染了事件链。

方法二：直接运行控制台命令

在控制台粘贴执行：getEventListeners(document).click?.map(l => l.listener.toString().slice(0,80))，回车。

如果返回多个包含 translate、word、popup 字样的匿名函数，那就确认了——多个翻译脚本正在同时监听全局点击事件，执行顺序一乱就会阻塞。

遇到这种情况，不要尝试手动删除监听器，因为扩展会自动重绑。唯一有效的动作是：卸载其中至少一个扩展，从根源上解决问题。