真正的防御必须从「锁定目标」和「识别模式」开始：只监听支付按钮、登录表单等关键容器，配置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，防不住全部。
