MutationObserver 的“原子性”指批量合并同一宏任务内的 DOM 变更并以微任务统一交付，而非保证单次 API 调用的原子性；其变更记录粒度由配置项决定，不跨宏任务边界合并。

MutationObserver 本身不保证“单个 DOM 操作”的原子性，但它天然具备批量合并变更记录的机制——这才是它处理节点变更时真正关键的“原子性”含义。

变更记录以微任务为边界批量交付

当多个 DOM 修改（如连续插入 5 个子节点、修改 3 次 class、删除 2 个元素）在一次 JS 执行上下文中发生时，MutationObserver 不会为每次修改触发一次回调。它会等到当前宏任务结束、所有同步脚本执行完毕后，在下一个微任务阶段，把这一批变动统一打包成一个 MutationRecord 数组，一次性交给回调函数处理。

• 这意味着你拿到的 mutationsList 是“本次 JS 执行周期内所有符合配置的 DOM 变动”的完整快照
• 哪怕中间夹杂了 Vue 的响应式更新、jQuery 的 append、原生 innerHTML 赋值，只要它们发生在同一轮事件循环中，都会被合并
• 这种批量交付避免了频繁重排重绘和回调开销，是性能优化的核心设计

单个 MutationRecord 不代表单次 DOM API 调用

一个 MutationRecord 对象描述的是某一类变化的逻辑单元，不是一一对应某行代码：

• type: 'childList' 的记录中，addedNodes 和 removedNodes 是 NodeList，可能包含多个节点——哪怕你只调用了 parent.append(a, b, c)
• type: 'attributes' 的记录里，attributeName 是单一属性名，但一次 el.setAttribute('style', '...') 可能触发多个样式变更，而 MutationObserver 只记录 style 属性本身的变更（除非开启 subtree 并监听后代节点）
• 没有“撤销”或“事务回滚”语义：它只报告发生了什么，不提供变更前/后的 DOM 树快照对比能力（需自行借助 oldValue 或手动缓存）

配置项决定“观察粒度”，而非操作粒度

所谓“原子性”实际由你设置的 config 决定哪些变更会被捕获、如何归并：

• childList: true + subtree: false：只捕获目标节点直系子节点的增删，深层嵌套变化不会拆分上报
• attributes: true + attributeFilter: ['data-id']：仅当 data-id 属性变化时才生成一条记录，其他属性改写完全忽略
• characterData: true：文本节点内容每次变动（哪怕只改一个字符）都会产生一条记录；若想合并，需在回调里自行做防抖或缓冲

无法跨任务边界保证原子性

如果两次 DOM 修改分别发生在两个宏任务中（例如 setTimeout、Promise.then、用户点击事件），它们一定会被拆成两次独立的回调调用：

• 第一次回调收到第一批变更记录
• 第二次回调收到第二批变更记录
• 中间若有异步逻辑（如 fetch 后插入节点），就自然形成隔离边界
• 这不是缺陷，而是设计使然：它让开发者能按自然的交互节奏响应变化，而非强行捆绑无关操作