Promise 在 JS 事件循环中何时执行？微任务队列的入队与清空时机

作者：闭包旅人

时间：2026-11-02

深入解析 Promise 在 JavaScript 事件循环中的实际执行时机，详细拆解微任务队列的入队条件、Microtask Checkpoint 清空机制、链式调用步进逻辑与常见混淆陷阱。

文章目录

JavaScript 核心原理事件循环 (Event Loop) 微任务机制 (Microtasks)

适用环境：浏览器 (Chrome/Firefox/Safari) / Node.js 主题类型：原理机制与实战时序剖析

在 JavaScript 中，Promise 的回调（then、catch、finally）并不会随着实例的声明立刻执行，但也绝不会推迟到下一个定时器之后。它的核心规则十分明确：只有当 Promise 状态转为 settled（已决议）且挂载了对应回调时，回调函数才会作为微任务（Microtask）压入微任务队列；而微任务队列的清空时机，就在当前同步调用栈彻底变空的瞬间（即当前宏任务执行完毕后），并在浏览器执行 UI 渲染或抽取下一个宏任务之前，一次性全数排空。

Promise 在 JS 事件循环中何时执行？微任务队列的入队与清空时机 — **图 1（概览）：**JavaScript 事件循环三阶段中微任务队列的绝对优先级位置

一、从一段看似矛盾的代码看起

设想你在排查一段前台组件初始化逻辑时，写下了如下看似寻常的代码：

// 场景：Promise 与定时器混合调度
console.log('1: 脚本顶层开始');

setTimeout(() => {
  console.log('2: 定时器宏任务执行');
}, 0);

new Promise((resolve) => {
  console.log('3: Promise 执行器内部');
  resolve();
}).then(() => {
  console.log('4: Promise.then 回调执行');
});

console.log('5: 脚本顶层结束');

实际控制台的输出顺序为：1 -> 3 -> 5 -> 4 -> 2。很多初学者常在这里产生两个关键误解：

误解一：以为写在 new Promise() 里面的代码就是异步代码。但实际上 3 甚至比 5 还要早打印。
误解二：以为 setTimeout(..., 0) 延迟为 0 毫秒就会“立刻”执行，为什么 4 却能够后发先至、强行插在 2 的前面？

要彻底掌握这个机制，必须把 Promise 的生命周期与事件循环的“双队列模型”拆解为两个具体的物理时机：回调何时被推进微任务队列？微任务队列又在什么临界点被调度清空？

二、Promise 执行的三段式：同步、注册与入队

一个 Promise 对象从实例化到最终执行回调，引擎内部经历了严格的三段操作：

1. 构造函数执行器（Executor）同步直通

传递给 new Promise((resolve, reject) => { ... }) 的函数被称为 Executor（执行器）。当代码执行到 new Promise 时，JavaScript 引擎会立即在当前调用栈同步调用此函数，不会进行任何异步延时。如果在执行器内第一行就是 resolve()，Promise 实例的内部私有槽位 [[PromiseState]] 会立即从 "pending" 翻转为 "fulfilled"，这一步依然完全是同步的。

2. 回调注册时机 vs 微任务入队时机

这是最容易产生认知偏差的地方：调用 .then() 本身并不等同于将回调立即送入微任务队列。引擎在执行 .then(onFulfilled) 时，会依据当前 Promise 实例的状态做出分流：

情况 A（状态已决议）：如果 Promise 的状态已经是 fulfilled 或 rejected（例如由 Promise.resolve() 产出，或者执行器内部已经同步调用了 resolve()），则引擎会立即将 onFulfilled 包装成一个 Microtask 节点，推入当前环境的微任务队列。
情况 B（状态仍为 Pending）：如果 Promise 内部执行的是异步操作（如 fetch 请求或延时器），在执行到 .then() 时，Promise 状态依然是 pending。此时微任务队列不会有任何动作！引擎仅仅把该回调函数保存在 Promise 实例内部的 [[PromiseFulfillReactions]] 列表中。直到未来某个时刻异步网络请求返回、显式触发了 resolve()，引擎才会在那个时刻把暂存的回调掏出并推入微任务队列。

核心判断依据

微任务入队的唯一充分必要条件：“Promise 状态已发生转变（Settled）” 且 “已经通过 then/catch/finally 注册了对应回调处理函数”。两者缺一不可。未决议时不入队，决议了但未绑定 then 亦不会生成微任务。

三、微任务队列的清空机制（Microtask Checkpoint）

微任务入队后，它在队列里等待。它究竟在什么时刻被调出来执行？HTML 规范将这一时机定义为 Microtask Checkpoint（微任务检查点）。

1. 宏任务边界与调用栈清空

JavaScript 运行时通过调用栈（Call Stack）执行代码。每一次事件循环迭代，引擎先从宏任务队列（Macrotask Queue / Task Queue）中取出一个最优先的任务（在页面初始加载时，整个 <script> 标签内的全局代码本身就是一个宏任务）。

引擎在调用栈中逐行同步执行这个宏任务。当最后一行同步代码执行完毕，调用栈深度归零（Call Stack is Empty）。就在控制权即将离开之前，引擎并不会立刻转向下一个宏任务，而是立刻触发微任务检查点！

2. “逢空必扫”：彻底排空特性（Drain to Completion）

微任务队列的处理逻辑与宏任务队列有着本质不同：

宏任务队列：一次事件循环 Tick 只取出一个宏任务执行。执行完毕后，控制权交出。
微任务队列：一旦微任务检查点被触发，引擎会开启一个循环：while (microtaskQueue.hasTasks()) { runNextMicrotask(); }。也就是说，它必须彻底清空整个微任务队列，才允许进行后续的 UI 渲染或调度下一个宏任务。

陷阱警示：微任务派生微任务与主线程饥饿

如果在执行某个微任务的过程中，又派生了新的微任务（例如在 then 回调里再次调用 Promise.resolve().then(...)），这个新微任务会被推入当前正在清空的队列末尾。因为清空循环的条件是“队列为空”，所以这些新微任务会在当前这一轮宏任务结束时被连续执行，而不会留到下一个宏任务之后。如果递归无节制地派生微任务，将直接导致宏任务（包括用户的点击事件、定时器以及页面的 UI 渲染）彻底被饿死（Starvation），页面表现为完全无响应卡死！

对比维度	宏任务 (Macrotask / Task)	微任务 (Microtask)
常见来源	整体 Script 脚本、`setTimeout`、`setInterval`、`setImmediate` (Node)、I/O、DOM 事件回调	`Promise.then/catch/finally`、`queueMicrotask()`、`MutationObserver`、`process.nextTick` (Node)
单轮执行数量	每轮事件循环只执行 1 个宏任务	每轮检查点必须连续完全清空所有微任务（包括派生任务）
调度清空时机	微任务清空完毕并完成屏幕渲染（若有必要）之后	当前调用栈刚刚清空、宏任务结束瞬间；UI 渲染启动之前
UI 渲染关系	宏任务执行完毕且微任务清空后，浏览器才计算 Style、Layout、Paint	微任务发生在渲染之前，因此微任务中修改 DOM 不会引起不必要的屏幕闪烁

四、时序解剖：经典混合代码执行步进拆解

为了加深理解，我们来观察一个涉及 Promise 链式调用与定时器的综合代码推演，跟踪调用栈、微任务队列与宏任务队列在各个时间点（T1 至 T5）的精确流转：

逐步推导细节：

第 1 行与第 13 行：属于顶层同步代码，直接入栈执行，先后打印 'A' 和 'E'。
第 2 行：setTimeout 被调用，浏览器定时器线程接管计时，到期后将回调注册进宏任务队列。
第 5~6 行：Promise.resolve() 返回一个已决议为 fulfilled 的 Promise。紧接着调用 .then()，因为父 Promise 已经 settled，所以其第一个回调（第 6~9 行，记为 then1）立即入队微任务队列。注意：此时第二个 then（第 10~12 行，记为 then2）还无法入队，因为 then1 还没有执行并返回结果，then1 返回的新 Promise 依然处于 pending 状态。
同步代码执行完毕：主线程全局上下文出栈，调用栈深度变为 0。微任务检查点触发！
清空微任务队列（第一步）：取出 then1 执行，打印 'C'，函数 return 'D'。这个返回值使得 then1 返回的 Promise 状态正式变为 fulfilled。由于状态变动，挂在它后面的 then2 此时正式获得入队资格并推入微任务队列！
清空微任务队列（第二步）：引擎检查微任务队列，发现刚刚进入了 then2，队列未空！于是继续出队执行 then2，打印接收到的参数 'D'。此时微任务队列彻底排空（Length = 0）。
进入渲染与下一宏任务：浏览器确认无需渲染，事件循环从宏任务队列中取出 setTimeout 的回调推入调用栈，执行并打印 'B'。

五、容易混淆的高频边界场景

1. async/await 底层等价于什么？

很多开发者在阅读 async/await 时容易迷失顺序。实际上，现代 JavaScript 引擎（遵循 ECMAScript 规范）对 await 的处理本质上就是 Promise 微任务的语法糖：

async function demo() {
  console.log('step 1');
  await getSomething();
  console.log('step 2');
}

// 上述代码在事件循环视角完全等价于：
function demoEquivalent() {
  console.log('step 1');
  return Promise.resolve(getSomething()).then(() => {
    console.log('step 2');
  });
}

只要记住：await 右侧的表达式是立即同步求值的；而 await 行之后的所有代码，全部都被打包放进了紧随其后的微任务回调中。因此 step 1 必然是同步输出，而 step 2 必须等待当前调用栈清空且微任务检查点触发时才执行。

2. 嵌套 Promise.resolve() 的微任务消耗

如果在 Promise.resolve() 内部再传入一个 Promise 实例（例如 Promise.resolve(Promise.resolve('val'))），规范规定如果传入的是真正的 Promise 实例，会直接将其返回，不额外增加微任务步骤；但如果传入的是一个带有 .then 方法的“类 Promise 假对象（Thenable）”，引擎会通过内部的 EnqueueJob 产生额外的微任务展开步骤。在日常业务开发中，直接使用标准原生 Promise.resolve(val) 即可确保预期的单步微任务时序。

六、总结与速查决策清单

理解 Promise 在事件循环中的执行位置，不需要死记硬背复杂的题目，只要掌握下面这张决策图谱：

三条核心准则速记：

执行器是同步的：new Promise(fn) 的 fn 立即在主调用栈执行，不要把它当成异步代码。
决议了才入队：.then() 回调只有在对应的 Promise 状态变为 settled 之后才会进入微任务队列；链式调用的下一个 then 必须等上一个 then 返回之后才入队。
宏任务后必清空：只要调用栈变为空，事件循环一定会先抽干所有微任务，然后才去处理 UI 渲染或下一个宏任务（如 setTimeout）。