MutationObserver 的批量处理由浏览器事件循环自动完成，同一宏任务内的 DOM 变更汇总为一次回调；跨宏任务（如 await、setTimeout、requestAnimationFrame）则触发新批次；配置项仅影响监听范围，不改变批量逻辑。
MutationObserver 的批量处理不是靠“智能合并”，而是浏览器在单轮事件循环的微任务阶段，自动把同一同步段内发生的全部 DOM 变更汇总成一个批次，统一触发回调。
它不依赖开发者写逻辑去“攒变更”，而是由浏览器底层调度机制保证：只要 DOM 修改发生在同一个宏任务（比如一次 click 处理函数、一次 Vue 更新、一段连续的 JS 执行），所有变动都会被收集到一个 MutationRecord 列表里，等当前宏任务结束、进入微任务队列时，一次性交给你的回调函数。
批量的边界由事件循环决定
- ✅ 同步代码中连续调用
el.appendChild()、el.setAttribute()、textNode.nodeValue = 'x'→ 全部归入一次回调 - ❌ 中间插入
await Promise.resolve()或setTimeout(() => {}, 0)→ 后续变更落入下一轮微任务，触发第二次回调 - ❌
requestAnimationFrame里的 DOM 修改属于新宏任务 → 必然分离，无法和前次合并
配置项影响的是“收哪些变更”，不是“怎么批量”
-
childList: true收节点增删 -
attributes: true+attributeFilter: ['class']只收 class 变更 -
subtree: true决定是否向下穿透监听
但无论开几个选项，只要它们发生在同一同步段，就进同一个mutations数组 —— 浏览器不按类型拆批，只按时间窗口聚堆。
真正需要手动干预的场景
浏览器的批量是自动的，但有时它不够用：
- 你想把 100ms 内所有变更（哪怕跨了多个宏任务）都合在一起处理 → 得自己套
setTimeout或debounce - 页面高频渲染（如拖拽、动画帧更新），回调太密 → 在回调里做去重或节流，比如只关注新增的
<button>元素，忽略中间过渡状态 - 某些操作（如
innerHTML = ...）会触发大量childList+characterData混合变更 → 提前用Array.from(mutation.addedNodes).filter(n => n.nodeType === 1)过滤出有效节点
批量本身不复杂，关键在于理解它被事件循环框死的节奏。想绕过这个节奏，就得在外层加控制，而不是改 MutationObserver 的配置。
