MutationObserver 的微任务特性与执行时机
概念要点
在浏览器的事件循环中，MutationObserver 回调不是同步执行的，而是在当前任务结束后以一个微任务的形式进入执行队列。该机制让开发者能够在 DOM 变更后立即获得通知，而不需要主动轮询。关键点包括：回调属于微任务队列、可能被同批变更合并为单次回调、以及它的触发通常发生在渲染前的阶段，为后续布局/绘制提供准备。
另外，MutationObserver 会对同一批 DOM 变更进行合并，形成一个批次的 mutations 记录并一次性回调，这样可以避免多次短时间触发带来的性能损耗。请注意：并非每一次变更都会触发一个独立回调，而是在一个微任务队列中统一处理。
实际执行时序的要点
在事件循环的宏任务结束（如一个事件处理回合、或一个脚本执行结束）之后，浏览器会清空微任务队列，依次执行其中排队的回调，随后进入下一个宏任务。对 MutationObserver 来说，这意味着：其回调在当前宏任务结束后执行，且在浏览器进入下一轮渲染前完成。若同一宏任务中还存在 Promise/queueMicrotask 等微任务，它们的执行顺序将依照排队的先后顺序来决定。
为了帮助理解，可以把事件循环简化为三步：当前任务执行完毕 -> 微任务队列被清空并执行 -> 下一宏任务开始执行。MutationObserver 的回调恰好被放入这个“微任务队列”的阶段，通常会在渲染之前触发，但具体触发时刻也可能受浏览器实现细节影响而略有差别。
与代码示例的直观对比
console.log('start');const box = document.createElement('div');
document.body.appendChild(box);const observer = new MutationObserver((records) => {console.log('[MO] mutations:', records.length);
});
observer.observe(box, { childList: true, attributes: true, subtree: true });// 触发 DOM 变更，这会将回调排入微任务队列
box.textContent = 'hello';// 同一宏任务中的其他微任务
Promise.resolve().then(() => {console.log('[Promise] microtask');
});queueMicrotask(() => {console.log('[queueMicrotask] microtask');
});console.log('end');
执行时机：当前任务结束后，接着执行的微任务队列
事件循环的简要图解
在浏览器中，宏任务是执行单位（如脚本、定时器回调、I/O 等），而 微任务在每个宏任务结束后被连续执行，直到队列清空为止。MutationObserver 回调作为微任务被排入队列，通常在当前宏任务结束后清空微任务队列并触发回调，从而尽快捕捉到 DOM 的最终状态。另一方面，Promise 的回调以及 queueMicrotask 产生的微任务也遵循同样的执行规则，因此它们之间的相对顺序由入队时的顺序决定。
在某些情况下，用户在同一宏任务中对同一 DOM 树连续修改多次，MutationObserver 可能只触发一次回调，并在一个批次中汇总多条变更。这一行为有助于降低重排和重绘的开销，并确保回调的可预测性。
实战要点
设计定位：如果你需要在 DOM 变更后尽快做出响应，MutationObserver 提供了一种低开销的观察机制，可以在微任务阶段完成处理并尽可能避免多次触发。
与渲染的关系：微任务通常在渲染前刷新布局和绘制，因此 MutationObserver 的处理往往能够在浏览器进行下一轮渲染前完成，减少可见的延迟。
与 Promise/queueMicrotask 的关系
微任务队列的共性与差异
无论是 MutationObserver、Promise 还是 queueMicrotask，它们的回调都属于同一个微任务队列，都在当前宏任务结束后被执行、且在下一轮宏任务开始前完成。为了避免混乱，最关键的记忆点是：微任务在同一轮事件循环中按入队顺序执行，不会被延后到下一个宏任务才执行，除非它们在不同的宏任务中被排入队列。
不过，MutationObserver 的回调具有一个特殊的“批处理”特性：它通常会把本轮 DOM 的变更打包成一个回调，一次性处理多条记录，从而降低多次回调带来的成本。
具体对比与示例
在同一个宏任务内部，若既有 MutationObserver 的回调，又有 Promise 的回调，它们的执行顺序取决于谁先被排入微任务队列。若先发生 DOM 变更并触发 MutationObserver 的回调，则该回调可能在后续的 Promise 回调之前执行，亦可能相反，取决于具体的排队时刻和浏览器实现。最可靠的理解是：都属于微任务，均在宏任务结束后逐个执行，顺序按入队先后决定。
为了明确对比，可以通过以下简短实验来观察执行顺序：当同一轮宏任务中既触发了 MutationObserver 的变更又创建了 Promise.then/queueMicrotask，观察输出即可得到具体执行顺序的直观印证。
实战示例：对比 MutationObserver 与 Promise 的执行顺序
对比实验代码
console.log('demo start');const target = document.createElement('div');
document.body.appendChild(target);const mo = new MutationObserver((records) => {console.log('[MO] records:', records.length);
});
mo.observe(target, { childList: true, attributes: true, subtree: true });target.setAttribute('data-test', '1'); // 触发 MutationObserverPromise.resolve().then(() => {console.log('[Promise] then');
});queueMicrotask(() => {console.log('[queueMicrotask] microtask');
});console.log('demo end');
在实际运行中，你会看到输出体现了“start -> end -> MO 回调 -> Promise 回调 / queueMicrotask 回调”的大致顺序，然而具体的顺序还会随着浏览器的实现和微任务的排队时机有所微调，因此在跨浏览器测试时请关注具体日志。
通过上述例子，可以清晰地看到：MutationObserver 的回调确实属于微任务，并且它的执行时机是在当前宏任务结束、进入下一个事件循环之前；同时，Promise/queueMicrotask 也是微任务，它们之间的相互影响取决于入队的具体时点和批处理行为。
