为什么我的代码在测试环境跑得好好的，一到用户电脑就崩？原来凶手躲在地址栏旁边

一、浏览器扩展：用户的朋友，开发者的噩梦

所谓浏览器扩展，也就是Chrome、Firefox以及Edge插件，从本质上来说，是运行于用户浏览器之中的第三方代码，它们具备着各种各样的权限。

对用户而言，这些权限属于“增强功能”，然而对于我们开发者来讲，它却是一颗不清楚何时会爆炸的雷。

1.1 最常见的“作案手法”

手法一：往 DOM 里塞私货

诸多广告拦截插件，会对页面之中的广告位予以扫描，随后将它们进行移除或者隐藏。然而要是你的代码恰巧依赖某一个被移除的DOM节点，那般便会费报错。

// 你写的代码
const adBanner = document.getElementById('ad-banner');
adBanner.addEventListener('click', trackAdClick); // 如果 adBanner 被插件删了，这里就报错

手法二：修改全局变量

存在一些插件，它们会朝着window对象之上挂载某些东西，举例而言，像是window.web3、window.ethereum这样的。要是插件代码存在着bug，又或者是覆盖了你自身的变量，那么便会引发冲突。

手法三：拦截并修改网络请求

有的比价插件，在页面加载之际，会更改fetch或者XMLHttpRequest，朝着请求之中增添参数，改变返回值。要是你的代码，对于返回数据格式有着严格的校验，那么就有可能崩溃。

手法四：注入大量 CSS 导致样式错乱

好多暗黑模式插件，会强制性地给页面增添 filter: invert(1)，如此一来，你那精心设计出来的渐变，以及精细设计的阴影，还有精心设计的图片，统统变为鬼片场景。

二、真实案例：一次被插件坑到怀疑人生的经历

去年，有用户反馈，我们网站的一个下拉菜单没法点开，我们团队用三台电脑都试过了，没有问题，后来让用户录屏，发现他浏览器右上角有一排插件图标，大概有七八个。

我让用户逐个将插件关闭进行尝试，当关闭至第三个时，也就是广告拦截器，此时菜单可以点击了。

过后进行排查时发现，那个广告拦截器存在一条规则，此规则将我们的菜单按钮识别成了广告弹窗，进而给它添加了display: none!important。

怎么办决方案呢？我们于 CSS 当中给菜单按钮增添了一条具备更高优先级的规则，而且更改了 HTML 结构，躲开了那个插件的检测规则。

自打那之后，我形成了一种习惯，在对“用户反馈然而本地没办法重现”的故障进行调试之际，先得问上一句，“你安装了哪些插件？”。

三、常见的“凶手插件”类型类型典型代表可能引发的问题

广告拦截器

AdBlock, uBlock Origin

移除 DOM 元素、阻止网络请求

安全/隐私插件

Privacy Badger, Ghostery

屏蔽第三方脚本、修改 Cookie

密码管理器

LastPass, 1Password

在密码框注入额外 UI，可能破坏表单提交逻辑

翻译插件

谷歌翻译、沙拉查词

修改 DOM 文本，可能破坏依赖文本内容的前端逻辑

暗黑模式插件

Dark Reader

注入全局 CSS，可能导致样式错乱

比价/购物助手

各种返利插件

修改商品价格、添加浮动按钮，可能遮挡你的 UI

油猴脚本

Tampermonkey

用户自定义脚本，什么都能干，什么都能坏

四、怎样进行检测以及防范“插件污染”呢？在4.1开发阶段，要运用插件来对自身加以测试。

于开发之际，提议安装若干常见的具“破坏性”的插件，时不时将它们开启去测试一下自身的页面。你会发觉诸多先前未曾想过的问题。

4.2 代码层面：防御性编程4.3 异常捕获与上报

在代码当中添加 try-catch，并且将错误信息进行上报。当用户把 bug 反馈出来的时候，能够从错误日志里找寻到点滴线索：

window.addEventListener('error', (event) => {
  // 上报错误，附带上用户安装了哪些插件（如果能检测到的话）
  reportError({
    message: event.message,
    filename: event.filename,
    // 可以尝试读取用户安装的插件，虽然不能完全读取，但部分插件会在 DOM 上留下痕迹
    extensions: detectExtensions()
  });
});

4.4 教用户“排除法”

当用户反馈 bug 时，可以提供一个标准操作：

将无痕模式开启（此模式默认情况下会把大部分插件禁用掉），要是无痕模式呈现正常的状态，那就表明是插件方面出现了问题，把插件逐个关闭，从而找出导致问题的那个插件。

这比你在本地猜来猜去要高效得多。

五、检测用户装了哪些插件（有限但有用）

然矣，汝不可径直读取用户所安装之全部插件，缘隐私之故也，然伱无妨借由某些“痕迹”做出推测。

function detectExtensions() {
  const detected = [];
  
  // AdBlock 检测
  if (document.querySelector('.adblock-warning') || 
      typeof window.adblockDetector !== 'undefined') {
    detected.push('AdBlock (可能)');
  }
  
  // 暗黑模式检测
  if (window.matchMedia('(prefers-color-scheme: dark)').matches) {
    // 这不一定是插件，也可能是系统设置
    detected.push('暗黑模式');
  }
  
  // 某些插件会在 body 上加特定 class
  if (document.body.classList.contains('darkreader')) {
    detected.push('Dark Reader');
  }
  
  return detected;
}

六、总结：拥抱不确定性

用户自主安装了浏览器插件，对此我们既无法禁止，也不应当禁止。然而，我们能够借助防御性编程，加上异常监控，再加上用户沟通，以使页面在面对这些“不速之客”之际变得更加健壮。

下一回，当你碰到那种“测试环境无异常状况，用户环境却出现错误提示”的程序漏洞状况时，暂且不要急着去怀疑自身所编写的代码，首先留意查看一下用户的地址栏附近区域——或许存在着一个体积微小的图标呢，它正神不知鬼不觉地给你的页面制造麻烦呢。

相关标签： # 浏览器扩展 # 插件污染 # 异常处理 # 用户体验 # 前端开发