真正的防御必须从「锁定目标」和「识别模式」开始：只监听支付按钮、登录表单等关键容器，配置childlist+subtree+attributes（限class/style/hidden），回调中快速筛检高危变更，修复前必disconnect，且需配合load事件等补位document.write等绕过场景。

直接监听 document.body 或全页节点，基本等于放弃防御——你会被广告轮播、统计脚本、框架重绘等合法变更彻底淹没，既收不到真正危险的信号，又拖慢主线程。真正的防御必须从「锁定目标」和「识别模式」开始。

只观察关键容器，别碰 document.body

恶意注入几乎不会随机发生，而是集中在业务敏感区域：支付按钮父容器、登录表单、法律声明块、客服入口、用户协议原文区。这些区域一旦被插件动过，风险极高。

• 用 document.querySelector 精准获取容器，例如 document.querySelector('#pay-button') 或带语义的 [data-role="legal-notice"]
• 绝对避免依赖动态 class（如 banner-123abc），优先用稳定 id 或自定义 data- 属性锚定
• 容器不存在时直接 return，不初始化 observer，防止空监听引发异常

配置 childList + subtree + attributes（带 filter）就够了

95% 的恶意注入行为逃不出这三类变化：加广告节点、删关键子元素、改 style 或 class 隐藏内容。其他选项纯属噪音源。

• childList: true —— 必开，捕获 script、iframe、div.ad-banner 等插入或移除
• subtree: true —— 必开，否则插件在 #pay-button > span > button 里塞节点你就完全看不见
• attributes: true + attributeFilter: ['class', 'style', 'hidden'] —— 只盯可能用于伪装/隐藏的属性；不开 attributeOldValue，省掉比对开销
• characterData: true —— 仅当监控法律文本等不可篡改内容时才开；普通业务区域可关

回调里做轻量判定，别写“全量比对”逻辑

每条 MutationRecord 都要快速过筛，不是所有变更都值得响应。重点看三件事：位置、类型、内容特征。

• 先用 targetEl.contains(mutation.target) 确认变更发生在目标容器内或其后代
• 若 mutation.type === 'childList'，遍历 mutation.addedNodes，用 node.matches('script[src*="cdn-malicious"], iframe[src*="adnetwork"]') 匹配高危节点
• 若 mutation.type === 'attributes' 且 mutation.attributeName === 'style'，检查 mutation.target.style.display === 'none' 或 visibility === 'hidden'
• 对 removedNodes 做存在性校验：比如 #real-submit-btn 被删，立刻告警，不等二次确认

修复前必须 disconnect，否则触发死循环

你在回调里调用 el.remove() 或 parent.replaceChild()，会再次触发 observer 回调——没有断开机制，两行代码就能让页面卡死。

• 修复动作前第一句必须是 observer.disconnect()
• 优先用 node.replaceWith(originalClone)，而不是 innerHTML = ''，避免清空整个结构引发连锁副作用
• 修复完再调用 observer.observe(target, options) 恢复监听，不要漏掉
• 高频场景（如轮播插件频繁切 class）建议加 setTimeout(..., 0) 合并处理，避免回调风暴

最易被忽略的是：MutationObserver 对 document.write、iframe 动态加载、Service Worker 注入等内容完全无感。这些路径需要配合 load 事件、iframe.onload 或 CSP 报告机制补位——光靠一个 observer，防不住全部。