JavaScript queueMicrotask 怎样安排微任务执行顺序

如果你只想把一段回调放到当前同步代码之后、下一次任务开始之前，queueMicrotask() 就是浏览器提供的直接入口。它不会打断正在执行的函数；当前任务结束后，浏览器处理微任务队列，先处理已经入队的微任务，再考虑后续任务。

官方参考：https://developer.mozilla.org/en-US/docs/Web/API/Window/queueMicrotask

queueMicrotask 的核心顺序可以记成：当前同步代码先完成，微任务按入队顺序处理，微任务队列清空后，后续任务才有机会执行。Promise.then 回调也处在微任务队列中；回调里再次调用 queueMicrotask，新回调会继续排到队列末端。

queueMicrotask 到底插在什么位置

浏览器把一次脚本执行看作一个当前任务。任务中的同步函数、条件判断和普通 console.log 会先沿着调用栈完成。调用 queueMicrotask(callback) 时，callback 不会立即调用，而是登记到当前环境的微任务队列。

当前任务返回后，事件循环会进入微任务检查点。微任务检查点的重点不是“等待一段时间”，而是把队列中待处理的微任务取出执行。MDN 对这个 API 的描述也是在当前任务完成、控制权回到事件循环之前执行回调。

用一个最小示例判断先后顺序

下面的示例只放入三类动作：同步输出、queueMicrotask 回调和 Promise.then 回调。代码中的注释说明每个动作的意图，示例本身不依赖具体框架。

// 先完成当前任务中的同步工作，再观察微任务的入队顺序
console.log('同步代码');

// 第一个微任务先登记到队列
queueMicrotask(() => {
  console.log('queueMicrotask');
});

// Promise.then 的回调也会进入微任务队列
Promise.resolve().then(() => {
  console.log('Promise.then');
});

// 这是当前任务里的最后一条同步语句
console.log('同步代码结束');

按浏览器微任务语义，输出顺序应是：

同步代码
同步代码结束
queueMicrotask
Promise.then

这里有两个容易漏掉的细节。第一，微任务不会插入两条同步输出之间，所以第一行和第二行先完成。第二，queueMicrotask 和 Promise.then 都是微任务，谁先登记，谁就先排在前面。这个判断只针对同一个事件循环代理和同一个当前任务上下文，不要把跨窗口、跨 Worker 的调度混为一谈。

微任务回调里再次入队会怎样

微任务回调执行时仍然处于微任务检查阶段。如果一个回调内部再次调用 queueMicrotask，新回调会追加到队列尾部。它不会被插到当前回调前面，也不会自动变成一个 setTimeout 任务。

// 用入队顺序说明微任务队列的尾部追加规则
queueMicrotask(() => {
  console.log('微任务 A');

  // A 执行时追加 C，C 排在当时已经入队的 B 后面
  queueMicrotask(() => {
    console.log('微任务 C');
  });
});

// B 先于 A 执行时新增的 C 留在队列中
queueMicrotask(() => {
  console.log('微任务 B');
});

这个示例的结构重点是“队列尾部追加”。开始时队列里已有 A、B；A 执行时再放入 C，因此处理顺序是 A、B、C。只要回调持续产生新的微任务，微任务检查阶段就可能持续更久，页面的后续任务和渲染机会也可能被推迟。

为什么 setTimeout 通常排在微任务后面

setTimeout 注册的是后续任务，不是当前微任务队列里的回调。把它和 queueMicrotask 放在同一段同步代码中时，当前任务结束后，浏览器通常先处理已经存在的微任务，再从任务队列中选择后续任务。

// 对比微任务和后续任务的调度归属
queueMicrotask(() => {
  // 微任务检查阶段中的回调
  console.log('microtask');
});

setTimeout(() => {
  // 后续任务中的回调，不能和微任务混用同一条队列解释
  console.log('task');
}, 0);

因此常见的观察顺序是 microtask 在前、task 在后。不过“0 毫秒”不是立即执行的承诺，计时器还会受到最小延迟、页面状态和浏览器调度策略影响。本文要判断的关键不是精确延迟，而是它们属于不同的调度边界。

什么时候适合使用 queueMicrotask

一个实用场景是让组件的同步路径和异步路径在通知时机上保持一致。例如，缓存命中时数据已经在手里，缓存未命中时要等异步请求；如果两条路径直接触发通知，调用方可能遇到不同的调用时机。把命中路径的通知放入微任务，可以让它至少不会在当前函数中同步重入。

// 让缓存命中分支也在当前调用栈退出后通知监听者
function notifyLoaded(listener, value) {
  // 空监听器直接结束，避免无意义的入队
  if (typeof listener !== 'function') {
    return;
  }

  // 微任务让调用方先完成当前同步状态更新
  queueMicrotask(() => {
    listener(value);
  });
}

使用时仍要留意三点：

• 不要在循环或相互触发的回调中无限入队，否则会让微任务队列迟迟不能清空。
• 不要把它当成延迟执行工具；需要明确的后续任务边界时，应使用计时器或其他合适的调度 API。
• 如果运行环境可能没有 queueMicrotask，先确认目标浏览器和 Web Worker 范围，再决定是否提供兼容封装。

常见问题

queueMicrotask 会不会立刻执行回调？

不会。调用时只是把回调加入微任务队列，当前同步任务仍然继续执行；当前任务结束后才进入微任务检查。

Promise.then 和 queueMicrotask 谁更快？

它们都进入微任务队列，通常取决于谁先登记。不能只因为 API 名称不同，就推断其中一个拥有独立的更高优先级。

回调里不断 queueMicrotask 会发生什么？

新回调会继续追加到微任务队列。若持续产生新微任务，后续任务与渲染机会可能被推迟，因此需要在业务逻辑中设置明确的停止条件。

最后可以用一句话复盘：queueMicrotask 不改变当前同步代码的执行顺序，它只把回调放进当前任务结束后的微任务队列；微任务按入队顺序处理，队列清空后才轮到后续任务。