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 后插入节点），就自然形成隔离边界
- 这不是缺陷，而是设计使然：它让开发者能按自然的交互节奏响应变化，而非强行捆绑无关操作
