MutationObserver 批量 DOM 更新的算法基础

MutationObserver 的批量 DOM 更新由浏览器事件循环的微任务队列天然聚合实现，而非算法控制；每次 DOM 变更同步生成 MutationRecord 并暂存，宏任务结束后统一执行回调，传入按序排列的全部记录，兼顾高效与非阻塞。

MutationObserver 的批量 DOM 更新不是靠算法实现的，而是浏览器内建的事件循环调度机制决定的——核心是微任务队列（microtask queue）与 DOM 变更记录的被动聚合。

浏览器内核同步记录变更

每次调用 appendChild、setAttribute、textContent = … 等操作时，浏览器内核会立即生成一条 MutationRecord，并存入内部变更队列。这个过程是同步、轻量、无回调触发的，不打断当前 JS 执行。

• 每条记录包含 type（如 ‘childList’）、target、addedNodes、oldValue 等字段
• 连续修改同一节点的 class 或多次插入子节点，可能被合并为单条或多条记录，而非一一对应
• 是否收录取决于 observer 的配置（如 childList: true、attributeFilter: [‘class’]）

微任务统一清空队列

当当前宏任务（如 click 处理函数、setTimeout 回调）执行完毕，JS 调用栈清空后，浏览器自动将所有已登记的 MutationObserver 回调推入微任务队列，并在本轮事件循环中一次性执行。

• 回调函数接收的 mutations 数组，就是该批次内全部变更记录，按发生顺序排列
• 它和 Promise.then()、queueMicrotask() 处于同一优先级，早于 requestAnimationFrame 和 setTimeout
• 此时 DOM 已完成所有修改，但页面尚未渲染——适合读取 offsetHeight 等布局信息

批量 ≠ 手动防抖，而是调度天然聚合

开发者无需写 setTimeout 或 requestIdleCallback 来“合并”变化；浏览器自动把同一宏任务内发生的多个合法变更打包处理，这是原生保障的行为。

• 10 次 appendChild → 触发 1 次回调，传入含 10 条记录的数组
• 先删节点、再加节点、再改 class → 全部归入同一次回调，顺序不变
• 不同宏任务中的变更，不会跨批合并（比如两个 setTimeout 中的操作，会触发两次回调）

对比旧方案：摆脱同步阻塞与轮询开销

废弃的 DOMMutationEvents（如 DOMNodeInserted）是同步触发的事件，每次变动都打断 JS 执行、强制重排重绘；而 MutationObserver 的批量机制从根源上规避了两类低效模式：

• 不轮询：省去 setInterval + querySelector 的 CPU 空转和重复查找
• 不阻塞：回调总在渲染前的空闲时机执行，不影响帧率与用户交互响应
• 可过滤：通过 attributes、attributeFilter、subtree 等配置，只让真正关心的变化进入队列