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 等配置，只让真正关心的变化进入队列
