MutationObserver 本质依赖微任务机制执行：DOM 变更同步记录为 MutationRecord，宏任务结束后自动以微任务入队回调，传入批量有序的 mutationsList，此时 DOM 为最终态但未渲染。
MutationObserver 本质上就是靠微任务机制来监听 DOM 变化的，不是“利用”微任务，而是它天然运行在微任务队列中——浏览器在每次宏任务结束后，自动把变更回调作为微任务推入队列，等同步代码跑完就执行。
微任务是它的执行基础
当你调用 observer.observe(target, config) 后，所有 DOM 修改（如 appendChild、setAttribute）会立即被记录，但回调不会立刻触发。浏览器把这些变化暂存为 MutationRecord，等当前点击事件、setTimeout 回调或 Promise 链彻底执行完毕，才把回调以微任务形式入队。
- 它和
Promise.then、queueMicrotask处于同一优先级，比setTimeout（宏任务）早得多 - 同一宏任务内发生的多次变动，只会合并成一次回调，传入一个含多条记录的
mutationsList - 回调里看到的 DOM 是 JS 操作完成后的“最终态”，但页面还没重绘，此时读取
offsetHeight会强制回流
怎么确保监听真正生效
光注册 observer 不够，关键在配置和时机：
-
必须显式开启对应类型：比如监听子节点增删，要设
childList: true；只监听 class 变化，得加attributes: true和attributeFilter: ['class'] -
深层监听要开
subtree: true：否则只响应目标节点自身的改动，后代节点变化不会被捕获 -
需要旧值就得配
attributeOldValue: true或characterDataOldValue: true，否则mutation.oldValue是undefined -
用完及时
disconnect()：组件卸载、弹窗关闭时必须断开，否则持续驻留内存，可能引发泄漏或误触发
配合 requestAnimationFrame 获取渲染后状态
因为 MutationObserver 回调发生在渲染前，若需真实布局信息（比如元素是否已出现在视口、准确高度），不能直接读取，得交给 requestAnimationFrame：
- 在回调里写
requestAnimationFrame(() => console.log(el.offsetHeight))，此时样式计算、布局、绘制都已完成 - 想等 DOM 更新+样式生效后再做定位或动画，这种组合最可靠
- 避免在回调中调用
getBoundingClientRect()或offsetTop，否则打断浏览器优化，拖慢帧率
适合什么场景，不适合什么
MutationObserver 不是万能补丁，它强在“批量 + 异步 + 精准时机”，但有明确边界：
- 适合：第三方 SDK 注入节点、富文本编辑器内容变化、动态广告位识别、评论区增量加载后初始化组件
-
不适合：高频实时输入反馈（该用
input事件）、纯状态驱动更新（该用框架响应式或queueMicrotask批量 render）、需要同步拦截的修改（它不支持 cancel） -
别和
setTimeout(0)混用：它更晚、不可控，还可能跨帧，破坏微任务的确定性
