MutationObserver 依赖微任务机制，其回调在当前宏任务结束后、页面渲染前统一执行，与 Promise.then 共享微任务队列，优先级高于 setTimeout，且自动聚合多次 DOM 变更以避免频繁开销。
MutationObserver 本身不是微任务，但它把回调函数放进微任务队列执行。它的响应时机紧随 JS 同步代码之后、页面渲染之前，既保证 DOM 已更新完毕，又避开阻塞渲染，是监听 DOM 变化的现代首选方案。
它怎么依赖微任务机制？
浏览器在同步执行 DOM 操作（如 appendChild、setAttribute）时，会立即记录变更，但不触发回调。这些变更被暂存为 MutationRecord，等当前宏任务（比如点击事件处理、脚本加载）彻底结束，主线程空闲时，所有已登记的 Observer 回调才被统一推入微任务队列执行。
- 和
Promise.then()、queueMicrotask()共享同一微任务队列，优先级高于setTimeout - 同一次事件循环中多次 DOM 修改，通常只触发一次回调——变化被自动聚合，避免频繁开销
- 回调执行时，DOM 已完成全部更新，但浏览器尚未绘制，此时读取
offsetHeight等布局属性是准确且安全的
它在 DOM 更新流程中处在什么位置？
MutationObserver 天然嵌入浏览器渲染流水线：DOM 修改 → 变更记录入队 → 微任务排队 → 回调执行 → （可选）requestAnimationFrame → 浏览器绘制。这个位置决定了它适合做“变化后立刻响应，又不影响渲染”的事情。
- 想获取更新后的尺寸或位置？直接在回调里读取，无需额外加
requestAnimationFrame - 需要等页面真正渲染完成再操作（比如截图、滚动定位）？在回调里调用
requestAnimationFrame即可 - 避免回调中再次修改 DOM 导致死循环？可在回调开头加防抖判断，或使用
observer.takeRecords()清空待处理队列
它和旧版 DOM 事件比有什么优势？
废弃的 DOMNodeInserted 等 Mutation Events 是同步触发的，每次 DOM 变动都立即执行回调，极易引发性能问题：
立即学习“Java免费学习笔记（深入）”；
- 同步调用可能造成回调嵌套过深，甚至栈溢出
- 频繁触发导致反复重排重绘，页面卡顿明显
- 无法合并连续变更，逻辑混乱、资源浪费
- MutationObserver 通过延迟 + 聚合 + 微任务调度，从根本上规避了这些问题
怎么写一个可靠的基础用法？
创建 Observer 实例后，必须显式调用 observe() 并传入目标节点和配置项，否则不会生效。常见配置包括 childList、attributes、subtree 等布尔开关。
- 监听子节点增删：
{ childList: true } - 监听属性变化并获取旧值：
{ attributes: true, attributeOldValue: true } - 监听整个子树：
{ subtree: true }（注意性能影响） - 停止监听时调用
observer.disconnect()，防止内存泄漏
