用 mutationobserver 监控 dom 必须限定目标容器、关闭冗余选项、回调内轻量匹配，修复前先 disconnect()，否则易拖垮性能或引发死循环；只监听具体业务节点，禁用全量监听 body，配置 childlist/subtree/attributes 铁三角，回调中精准校验变更类型与特征，修复前断开观察器。
直接上结论：用 MutationObserver 监控核心 DOM，必须限定目标容器、关闭冗余选项、在回调里做轻量特征匹配，修复前先 observer.disconnect()——否则不是防不住，而是自己先被拖垮或触发死循环。
只监听具体容器，别碰 document.body 或 document
监听整个页面等于主动放弃判断能力。广告 SDK、客服浮窗、A/B 测试脚本每秒都在改 body，你一开全量监听，回调里 99% 的记录都是噪音。
- 精准定位业务关键节点，比如：
document.querySelector('#pay-button')、document.querySelector('[data-role="legal-notice"]')、document.querySelector('.auth-form') - 优先用
id或带语义的data-属性，避开插件动态生成的 class（如zopim-123abc） - 如果容器是异步加载的，加个
setTimeout或配合requestIdleCallback延迟初始化，避免querySelector返回null
childList + subtree + attributes 是铁三角配置
第三方插件篡改就这三类动作：塞新节点、钻到深层改东西、偷偷动属性。少一个就漏报，多一个就误报或卡顿。
-
childList: true—— 必开，捕获script、iframe、div.ad-banner等插入行为 -
subtree: true—— 必开，否则插件在#pay-button > span > i里塞水印图标你就完全看不见 -
attributes: true+attributeFilter: ['class', 'style', 'hidden', 'data-*']—— 只盯可能影响功能或隐藏内容的属性，不设attributeFilter会白增 30%+ 回调开销 -
characterData: true—— 仅当法律声明、版权信息等文本内容需防篡改时才开；普通业务区域不开，极少有插件直接改 textNode - 别开
attributeOldValue和characterDataOldValue—— 你不需要比对“原来是什么”，只需要“现在是不是可疑”
回调里不做全量遍历，只查三件事
回调函数执行越快越好，主线程卡住一秒，用户就可能点错支付按钮。别写 node.querySelectorAll('*') 这种操作。
- 先确认变更是否落在目标容器内：
if (!targetEl.contains(mutation.target) && mutation.target !== targetEl) return; - 如果是
childList类型，只检查mutation.addedNodes中的节点是否匹配恶意特征：node.matches('script[src*="malicious"], [id^="ad-"], [class*="taboola"]') - 如果是
attributes类型，只看是否动了关键属性：mutation.attributeName === 'style' && /none|hidden/i.test(node.style.display || node.style.visibility) - 遇到
removedNodes里包含关键子节点（如#real-submit-btn），立即告警，不等下一轮
修复动作必须断开观察器再执行
这是最容易被忽略也最危险的一环。你在回调里调 el.remove() 或 el.classList.remove()，会再次触发 MutationObserver 回调——没做防护就是无限递归，浏览器直接卡死。
- 修复前第一件事：
observer.disconnect() - 修复后如果还需继续监控，再调一次
observer.observe(targetEl, config) - 优先用
node.replaceWith(originalClone)或el.textContent = originalText，避免用innerHTML引入 XSS 风险 - 高频变动场景（如轮播图插件频繁切 class），加个 100ms 节流：
if (Date.now() - lastHandleTime
真正难的不是写几行 MutationObserver 代码，而是想清楚：哪个容器算“核心”，哪些变更算“恶意”，以及修复动作本身会不会变成新的攻击面。这些判断没法靠工具自动生成，得结合业务逻辑一条条过。
