MutationObserver 回调位于微任务队列，行为是同步注册、异步执行、批量合并、微任务调度；它在同步脚本结束后立即执行，优先级高于宏任务但与 Promise.then 同级，且自动合并多次变更。
MutationObserver 的回调既不是完全同步，也不是传统意义上的异步（比如 setTimeout 那种宏任务），它落在微任务队列中——这是理解“同步与异步边界”的关键。
它的行为本质是：同步注册、异步执行、批量合并、微任务调度。这种设计天然平衡了响应及时性与性能开销。
回调触发时机明确属于微任务
- DOM 修改操作（如 appendChild、setAttribute）本身是同步的，但 MutationObserver 不会在修改后立刻执行回调。
- 浏览器会把所有符合观察配置的变更暂存，等当前同步脚本执行完（即调用栈清空），立即在微任务阶段统一触发回调。
- 它和 Promise.then、queueMicrotask 处于同一优先级，早于 setTimeout、requestAnimationFrame 等宏任务。
例如：
console.log('1');
root.appendChild(new Text('a'));
console.log('2');
Promise.resolve().then(() => console.log('3'));
new MutationObserver(() => console.log('4')).observe(root, { childList: true });
console.log('5');
// 输出顺序：1 → 2 → 5 → 4 → 3这里 4 在 5 后、3 前，说明它确实在同步代码结束后、其他微任务之前或之中执行（具体取决于浏览器实现细节，但总在宏任务之前）。
批量合并机制降低冗余调用
- 连续多次 DOM 变更（哪怕在同一个 tick 内）会被合并成一次回调，传入的
mutations是数组。 - 这避免了“每次插入一个节点就触发一次回调”的高频开销，也意味着你不能依赖回调次数与 DOM 操作次数一一对应。
常见需注意的点：
- 不要假设回调能反映“实时状态”，它反映的是变更快照，且可能跨多个操作。
- 若需精确追踪某次插入，建议在插入前打标记（如临时 data 属性），或结合 requestIdleCallback 做后续处理。
异常不影响观察器持续运行
- 回调中抛出未捕获错误，不会终止 observer，也不会阻塞后续变更的监听。
- 错误会冒泡到全局（触发 window.onerror），但 observer 本身继续工作。
- 建议在回调内做 try/catch，尤其当处理动态节点时容易遇到已被移除的 node。
配置项直接影响“何时触发”与“触发粒度”
-
childList: true+subtree: false：只监听目标元素直系子节点变化。 -
subtree: true：监听整个子树，但大量深层嵌套变动可能导致单次回调携带数百条 mutation 记录。 -
attributeFilter: ['class']：缩小监听范围，减少无用触发。
合理配置能让回调更聚焦，间接提升“响应感”——看起来更“及时”，实际仍是微任务，但减少了无效合并与计算。
基本上就这些。
