MutationObserver 回调是微任务，但需等同步脚本执行完、DOM 变动批量汇总后才触发，响应的是本轮变更的最终快照而非实时修改；其优先级略高于 Promise.then，且在渲染前执行，适合变更后清理而非动画帧响应。
MutationObserver 的回调是微任务，但它不是“一改 DOM 就立刻执行”，而是等当前所有同步脚本执行完、DOM 变动批量收集完毕后，才作为微任务进入队列。它不响应单次修改，而是响应“本轮 DOM 变动的最终快照”。
它为什么是微任务，但又不等于“马上执行”
MutationObserver 回调被加入微任务队列的时机，是在当前宏任务结束前、微任务清空前——但前提是浏览器已完成对本次脚本中所有 DOM 操作的记录与合并。也就是说：
- 你在一段同步代码里连续增删 5 个节点，MutationObserver 不会触发 5 次，而是在这串代码执行完后，一次性汇总成一条 mutation 记录，再以一个微任务执行回调
- 这个微任务和 Promise.then 处于同一优先级，会在当前宏任务结束后立即执行（只要微任务队列没被自己递归塞爆）
- 它不会打断同步执行，也不会在 DOM 修改中途介入；它的“异步”是为避免高频抖动，本质仍是微任务调度
它和 Promise.then 的执行顺序关系
两者同属微任务，但浏览器规范规定：MutationObserver 回调优先级略高于 Promise.then（在 Chrome、Firefox 等主流引擎中）。这意味着：
- 如果同一轮微任务中同时有 MutationObserver 回调和 Promise.then，前者通常先执行
- 不过这种优先级差异不应用于业务逻辑依赖——因为规范未强制要求，Node.js 中甚至不支持 MutationObserver
- 真正可靠的做法是：把需要“响应 DOM 状态”的逻辑统一放在同一个微任务上下文，比如全用 queueMicrotask 包裹，或在 MutationObserver 回调里主动触发 Promise 链
怎么验证它确实发生在渲染前？
关键不在“是不是微任务”，而在“是否赶上了本次渲染的判定窗口”。可这样验证：
立即学习“Java免费学习笔记（深入）”；
- 在 click 事件（宏任务）中修改 DOM → 立即触发 MutationObserver 微任务 → 在其回调里读取 offsetHeight 或 getComputedStyle → 值已更新，说明样式计算尚未发生
- 若在 MutationObserver 回调里再加一个 setTimeout(() => ..., 0)，里面的代码就一定在下一次渲染之后执行
- 注意：如果同步代码末尾已触发强制重排（如读 offsetTop），浏览器可能提前进入样式计算阶段，此时 MutationObserver 回调虽是微任务，但已错过“干净”的渲染前时机
实际使用时的关键提醒
MutationObserver 不是 DOM 变化的实时监听器，而是“本轮变更收尾通知器”。因此：
- 不要指望它捕获中间态（比如插入节点 A → 改 class → 插入节点 B，你收到的是含 A、B 和 class 更新的完整记录）
- 它适合做“变更后清理”“状态同步”“自动初始化子组件”等场景，不适合做“每步动画帧响应”
- 记得调用 disconnect() 避免内存泄漏；观察范围尽量精确（childList、attributes、subtree 等选项按需开启）
