MutationObserver 的高效性源于其基于微任务的批量处理机制：变更被暂存为 MutationRecord，待宏任务结束后统一回调，确保 DOM 最终态可见但未渲染；需合理配置 observe 选项并及时 disconnect 避免内存泄漏。
MutationObserver 的高效性，核心在于它不打断当前脚本执行，也不在每次 DOM 修改时立刻响应，而是把变化“攒起来”，等 JS 主线程空闲了再统一处理——这背后是浏览器事件循环中微任务（microtask）机制的精准调度。
它怎么做到“不抢话筒”又不丢变化？
当你调用 element.appendChild() 或修改 className 时，浏览器内核会立即同步记录这次变更，生成一条 MutationRecord，但不会触发回调。这些记录被暂存在内部队列里，轻量、无开销、不影响当前代码流。
- 连续 20 次添加子节点，通常只合并为 1 条 childList 类型的记录，而非触发 20 次回调
- 哪怕你在一次点击事件里同时改 class、增节点、更新文本，最终也只进一次微任务回调
- 回调执行时机严格固定：当前宏任务（如事件处理、setTimeout 回调）结束后，立刻清空微任务队列
为什么回调里 DOM 是“最终态”却还没渲染？
因为微任务位于宏任务之后、渲染之前。你在回调中读取 offsetHeight 或 getBoundingClientRect()，拿到的是所有 JS 操作完成后的 DOM 结构，但页面尚未重绘——此时若需布局信息，得配合 requestAnimationFrame。
- 想判断元素是否已出现在视口？不能只靠 MutationObserver 回调，要加 requestAnimationFrame 做二次确认
- 需要在 DOM 更新后立即调整样式？可在回调中设置 class，再在 rAF 里读取计算样式
- 避免在回调中触发强制同步布局（如 offsetTop），否则可能引发重排抖动
配置不当，再好的机制也白搭
observe 的配置项不是可有可无的开关，而是直接影响性能和数据精度的关键控制点：
- subtree: false 是默认值，意味着只监听目标节点自身——若想捕获子元素插入，必须显式设为 true
- 只关心 disabled 属性？用 attributeFilter: ['disabled']，避免监听 class/style 等无关变动
- 要对比属性修改前后的值？除了 attributes: true，还得加 attributeOldValue: true
- 监听文本变化却没看到回调？检查是否漏了 characterData: true，且目标是 TextNode 而非 Element
别忘了“收尾”：disconnect 不是可选项
在单页应用组件卸载、弹窗关闭或临时监听结束时，必须调用 observer.disconnect()。否则观察器仍驻留在内存中，持续接收并排队变更记录，可能造成内存泄漏或意外触发旧逻辑。
- React 中可在 useEffect 的清理函数里调用 disconnect
- Vue 中建议在 beforeUnmount 钩子中清理
- 手动创建的 observer，应与目标节点生命周期对齐，避免“监听了没人管”的悬空状态
