MutationObserver使用教程：监控属性与子节点变化

MutationObserver 是一个强大但极易踩坑的 DOM 变化监听工具，其回调不触发往往并非 API 用错，而是源于目标节点失效、配置漏项或监听策略与业务场景严重错配：比如在 DOM 挂载前 observe、误用 property 赋值监听 class/style、忽略 subtree 导致深层变动漏捕、未用 attributeFilter 和 attributeOldValue 引发性能雪崩——真正难点不在“怎么写”，而在“何时监听、监听谁、监听什么变化”，掌握节点生命周期、属性变更机制与粒度控制，才能让 MutationObserver 稳准快地服务于防篡改、动态响应等关键场景。

为什么 MutationObserver 回调完全不触发

最常见原因是配置漏项或目标节点失效。只写 new MutationObserver(callback) 不够，必须显式调用 observer.observe(target, config)；如果 target 是 document.getElementById('xxx') 但元素还没挂载（比如 Vue 的 setup() 里提前查），target 就是 null，observe() 不报错但静默失败。

另一个高频坑：监听 document.body 或 document —— Safari 旧版本不稳定，应锁定具体容器，如 #app 或 .content。

• 检查 target 是否真实存在：console.log(target) 确认非 null
• 确保 observe() 在 DOM 挂载后执行（Vue 用 onMounted，React 用 useEffect）
• 避免监听顶层节点，改用业务容器节点

监听 class 或 style 属性变化总收不到回调

因为 el.className = 'active' 和 el.style.color = 'red' 修改的是 DOM property，不是 HTML attribute，MutationObserver 默认不捕获。只有 setAttribute('class', ...) 或 removeAttribute('style') 这类操作才会触发 attributes: true 监听。

data-* 属性是唯一“天然适配”的类型：无论用 setAttribute('data-id', '123') 还是 el.dataset.id = '123'，底层都走 attribute 接口，必触发。

• 要监听 class，必须用 el.setAttribute('class', ...)，不能依赖 classList.add()
• 想响应 classList 操作，得封装或改用 Proxy，MutationObserver 本身无解
• 在 attributeFilter 中写 'class'，不是 'className'
• 大小写敏感：data-user-id 对应 dataset.userId，但 mutation.attributeName 拿到的是 'data-user-id'

childList: true 为什么只监听到新增、没反应删除

childList: true 本身就能同时捕获 addedNodes 和 removedNodes，不需要额外开关。问题常出在回调处理逻辑里：被删节点已脱离文档树，removedNodes[0].offsetHeight 会是 0，.querySelector 会返回 null，直接读取可能报错或误判为空。

另外，childList: true 默认只监听目标节点的**直接子节点**。如果动态插入发生在深层嵌套里（比如 #list > .item > span 被替换），而你只观察 #list 且没开 subtree: true，就收不到。

• 回调中立刻缓存被删节点：const nodes = Array.from(mutation.removedNodes)
• 区分新增/删除：检查 mutation.type === 'childList' 后，看 mutation.addedNodes.length 和 mutation.removedNodes.length
• 需要监听后代节点变动时，必须加 subtree: true，否则深层插入无效
• 仅监听一级列表增删（如评论区 .comment），关掉 subtree 更轻量

怎么精准监听几个关键属性又不拖慢页面

不设 attributeFilter 会监听所有属性变更，包括框架频繁修改的 class、style、id，导致回调爆炸；不设 attributeOldValue: true，则 mutation.oldValue 永远是 undefined，无法比对是否真变了。

性能损耗主要来自监听范围和回调频率，而非 MutationObserver 本身。开 subtree: true + attributes: true 却没过滤，等于让浏览器每帧扫一遍整个子树的所有属性。

• 只监听真正关心的属性：attributeFilter: ['data-status', 'disabled', 'aria-expanded']
• 必须加 attributeOldValue: true 才能拿到旧值，否则比对逻辑失效
• 若目标只是防篡改（如支付按钮），把 target 锁死到那个元素，别监听父容器
• 修复属性后记得先 observer.disconnect()，再 setAttribute()，最后重新 observe()，避免循环触发

实际中最容易被忽略的点是：**监听范围与业务粒度不匹配**。比如为防 class 篡改而去监听整个 #app，结果被轮播图自动切换 class 淹没；或者想监听某个弹窗的 data-open，却忘了它由框架动态挂载，observe() 调得太早。这些都不是 API 写错了，而是目标节点生命周期和监听策略没对齐。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《MutationObserver使用教程：监控属性与子节点变化》文章吧，也可关注golang学习网公众号了解相关技术文章。