MutationObserver 的批量处理由浏览器自动完成：同一宏任务内的 DOM 变更会被聚合成一次回调，含所有记录；跨宏任务（如 await、setTimeout、requestAnimationFrame）则触发新回调；配置项仅影响监听范围，不改变批量逻辑；高频场景需手动节流，注意及时断开监听以防泄漏。
MutationObserver 处理批量 DOM 变化不是靠开发者手动“攒”变更，而是由浏览器事件循环自动完成的——关键在于理解它的触发边界和如何配合使用。
批量由微任务自动聚堆
同一宏任务内（比如一次 click 回调、一段连续脚本）发生的全部 DOM 修改，会被浏览器暂存，在宏任务结束后统一打包进一个 MutationRecord 数组，触发一次回调。这意味着：
- 连续调用
el.appendChild()十次 → 只触发一次回调，mutations数组含十条记录 - 中间插入
await Promise.resolve()或setTimeout→ 后续变更落入新宏任务，必然触发第二次回调 -
requestAnimationFrame内的 DOM 操作属于新宏任务，无法与前次合并
配置只决定“收什么”，不决定“怎么批”
是否启用 childList、attributes、subtree 或设置 attributeFilter，只影响哪些变动被纳入监听范围，不影响批量逻辑本身：
- 只要变动发生在同一同步段，无论类型如何，都会进入同一个
mutations数组 - 开
attributes: true+attributeFilter: ['class']，只会收 class 变更，但多个 class 变更仍归为一批 - 关闭
subtree: false后，后代节点变动不会触发回调，但目标节点自身的变更仍按原规则批量处理
高频场景需外层干预
浏览器的自动批量只覆盖单个宏任务，若想跨任务聚合（如 100ms 内所有变更），就得自己加控制：
- 用
setTimeout或debounce延迟处理，把多次回调合并为一次业务逻辑 - 在回调里做轻量过滤：例如只关注
mutation.addedNodes中的元素节点，跳过文本节点或注释节点 - 对大量
innerHTML =引发的混合变更，提前用Array.from(mutation.addedNodes).filter(n => n.nodeType === 1)提取有效节点
避免无效监听和内存泄漏
批量本身高效，但监听失控会抵消优势：
- 组件卸载、弹窗关闭时务必调用
observer.disconnect() - 不要长期监听
document，优先锁定具体容器节点 - 不需要旧值时，别开
attributeOldValue或characterDataOldValue，减少内存占用 - 频繁重连可用
observer.takeRecords()清空队列后复用实例，而非反复新建
