能监控，但必须聚焦“安全属性”本身——只捕获class、style、disabled、data-*等直接影响行为或可见性的属性，并在回调中做语义级判定；因attributeFilter不支持通配符且硬编码易失效，需启用attributes: true + attributeOldValue: true手动比对变更。
直接结论：能监控，但必须聚焦“安全属性”本身——不是监听所有属性变更，而是只捕获 class、style、disabled、data-* 等直接影响行为或可见性的属性，并在回调中做语义级判定，否则等于白开。
为什么不能直接用 attributes: true + attributeFilter
因为 attributeFilter: ['class', 'style'] 在实际中几乎无效：浏览器对通配符（如 'data-*'）不支持，传进去会被静默忽略；而硬写全量 data-original-amount、data-auth-required 等字段又极易失效——第三方插件常动态生成 data 属性名。真正可靠的做法是开启 attributes: true + attributeOldValue: true，然后在回调里手动比对变更前后的值，只响应那些导致功能降级或视觉隐藏的操作。
哪些属性变更算“安全风险”，要立刻拦截
不是所有属性修改都危险，关键看是否破坏用户可控性或信息完整性：
-
class被移除is-enabled或添加hidden-by-sdk类 → 按钮不可点 -
style新增display: none或opacity: 0→ 关键文案/按钮消失 -
disabled从false变为true→ 表单控件被锁死 -
data-*属性被注入伪造值（如data-verified="false"覆盖真实状态）
回调里怎么快速判定一次属性变更是否恶意
别遍历所有 mutation，先做三层轻量过滤：
- 跳过非目标容器：
!target.closest('#pay-section, #login-form, [data-role="auth"]') - 只处理
mutation.type === 'attributes'且mutation.attributeName在白名单中（['class', 'style', 'disabled', 'readonly', 'data-status']） - 比对旧值与新值：
if (oldValue === null && newValue !== null && newValue.includes('none'))→ 高概率是隐藏操作
修复时最容易踩的坑：自己触发二次回调
一旦确认篡改，修复动作必须原子化且隔离：
- 调用
observer.disconnect()再修改 DOM，修完再observer.observe()—— 否则el.classList.remove('hidden-by-sdk')会再次进回调，可能死循环 - 避免用
innerHTML重写整个容器，优先用el.setAttribute('class', originalClass)或el.disabled = false - 对高频区域（如客服浮窗容器）加节流：
if (Date.now() - lastFixTime
真正难的不是监听，而是定义“什么是安全”——比如 data-tracked="true 是埋点需要，data-tracked="blocked" 才是干预信号。这个边界必须由业务方明确，MutationObserver 只负责忠实传递变更事实。
