免费 Chrome 商店扩展发了 12 条——永久封禁。主人以为是发送速度。实际是与速度无关的技术痕迹暴露了他。多数「扩展检测」文章把真实浏览器机制与论坛猜测混作 Meta 官方立场。
WhatsApp 更新 Web 客户端防护比论坛更新手册更快：半年前「管用」的今天可能赔上号码。读完后你会分清哪些流行解释有 Meta 文档与浏览器规范支撑，哪些该扔掉。
WhatsApp Web 是普通网页。读取聊天、插入文案或代点「发送」的扩展必须在页面内执行 JavaScript 并改 DOM——否则物理上无法工作。与 Puppeteer/Selenium 自动化同属灰色传输——只是浏览器插件形态。
须分清两个说法。已装扩展完整列表页拿不到——浏览器对任何站点（含 WhatsApp Web）隔离。但扩展在 WhatsApp Web 标签页内所做——多余标签、拦截点击、程序化插入文本——技术上可观察，因与 WhatsApp Web 本身同执行环境。
差别细微却改变全貌：WhatsApp 并非「扫描你的浏览器」——至多看到自己页面内扩展工作的后果。下文：哪些后果真被用、哪些仅存于论坛转述。
「WhatsApp 通过 Code Verify 校验代码哈希从而检测扩展」几乎每篇相关文章都有——错不在细节而在方向。
之前（常见写法）： Code Verify 是 WhatsApp 检查你浏览器代码、抓外来改动的机制。
之后（实际）： Code Verify 是用户自愿安装（Chrome/Firefox/Edge）的扩展，用于反向确认 WhatsApp Web 代码未被替换——如 MITM 或网络层篡改。哈希在用户侧本地对照 Meta 经 Cloudflare 发布的参考值。
摧毁迷思的细节：Meta 官方说明该扩展不向 WhatsApp 或 Meta 报送运行数据——明确称公司不知你是否安装。技术上 Code Verify 不能是检测群发扩展的工具——方向相反，是用户自检，非监视用户。
故流行建议「关掉 Code Verify 才能群发」毫无意义：物理上不向 WhatsApp 报告的扩展无法影响是否被封——它从来不是监视工具。
已确认：群发扩展加自有 UI（启动钮、文本框）或直接读写聊天 markup，否则无法工作。
未确认：WhatsApp Web 前端用 MutationObserver 专搜群发扩展并在发现外来 DOM 节点时自动封号。论坛流行，无官方确认亦无官方否认。
更大胆理论：扩展用 display: none 藏界面（如左侧聊天栏）腾 UI 位，WhatsApp 立刻断会话——BlackHatWorld 式内幕，非文档事实，作假设非操作指南。
实践结论： 扩展越重改页面，技术痕迹越多——无论 WhatsApp 当下是否使用。反垃圾更新快于论坛手册。
全题最可靠部分——唯一可不含糊陈述的。
扩展对「发送」程序化 click() 或经 DOM API 插文，浏览器生成 Event.isTrusted = false 事件——浏览器按规范设置，普通页面 JS 或扩展 content script 原则上无法改写。属于更广行为反垃圾逻辑。
| 信号 | 人 | 基础扩展 |
|---|---|---|
Event.isTrusted |
true |
false |
| 动作前光标移动 | 有、不均匀 | 常无 |
| 按键间隔 | 随机 80–300+ ms | 常 0 ms 即贴入 |
| 输入前焦点 | 自然 | 可能缺失 |
所见技术审计中此链几乎总是重复：isTrusted = false 下明显发量账号，群发开始后平均 5–15 分钟内封。非 Meta 官方数字——实践观察——但稳定可作参考。
由此生出整片「人类模拟」市场：高级工具设每字 50–150 ms、消息间随机暂停 15–45 秒。降低某一具体风险，但不改变事实：普通 content script 无更低层浏览器 API 时 isTrusted 仍为 false。
Chrome/Firefox 扩展各有 Extension ID。论坛理论：页面经 chrome-extension:// 请求扩展资源，借 PerformanceResourceTiming API 响应事实或速度判断安装了什么。
经 web_accessible_resources 指纹扩展的方法技术上存在、安全研究者有述——非臆造。但「WhatsApp Web 刻意扫描特定群发扩展 ID」无确认——或可解释部分封禁，或与 isTrusted 等信号巧合。
间接论据此域确有攻防：「灰色」扩展开发者越来越多地混淆 web_accessible_resources 路径、每次重装改 Extension ID——为使指纹失效。方法若完全无用，不会投入绕过。
起步失败多数几乎一样——同类典型例。
案例 1——失败。 营销人员装免费 Chrome 扩展，载入 200 号冷名单开流。12 条后页面重载、永久封。技术分析：扩展直接 DOM 插文并程序化 click()——经典无伪装 isTrusted = false 链。
案例 2——复杂模拟。 另一运营配反检测浏览器 + Puppeteer stealth（如 puppeteer-extra-plugin-stealth），经 CDP 在浏览器层而非页面层改值，加贝塞尔光标轨迹。温热名单上账号撑更久、每号日发 80–100 条。
非教程、非结果保证。调试协议访问使扩展笨重、对浏览器本身显眼、每次 Chrome 更新不稳。此处技术成功 ≠ 业务安全——只是同一场更贵赛跑，迟早也会过时。
亦点出群发扩展卖家爱用的营销句：「对 WhatsApp 完全不可见」。无独立审计证实，isTrusted 架构与 Code Verify 反而说明——完全不可见未获技术证明，且与浏览器事件机制矛盾。
行业争 DOM 与 isTrusted 时，旁侧有文档更充分的检测通道：收件人举报。
WhatsApp Business 按多少人拉黑或举报赋质量评级——绿、黄、红。评级下降限制送达并可致封，与 isTrusted 多干净无关。详见指标与举报阈值。
技术侧再完美，冷名单收件人大规模举报仍救不了。举报是全题最无聊、最被低估的信号。
| 机制 | 状态 | 实践含义 |
|---|---|---|
| Code Verify 校验客户端代码 | 已确认，方向相反 | 用户自检，非监视 |
Event.isTrusted 区分点击 |
浏览器规范确认 | 最可靠技术信号 |
| 举报质量评级 | WABA 政策确认 | 与代码无关的检测通道 |
MutationObserver 搜扩展 |
未确认 | 合理但未证理论 |
| Resource Timing 查 Extension ID | 未确认 | 方法存在，WA 是否用——无 |
| 藏 CSS 即登出 | 未确认 | 论坛轶事 |
单凭一个 isTrusted = false 即封 |
未确认为唯一原因 | 更似信号集之一 |
多账号基础设施尤甚：每增一号放大触达与风险面——同一技术痕迹在所有号码重复。见账号分配与养号农场。
用当前扩展对照上表：是否直接插文、是否无模拟 click()、界面改动多大——无需猜论坛即可看真实风险。
群发体量超出个人使用——考虑官方 WhatsApp Business Platform——唯一规模与自动化本身不违平台规则的通道。
实践规则：
扩展不是在骗 WhatsApp——只是还没被抓。按明天就会被抓来建流程，别按永远不会。
