微任务队列与Promise执行顺序详解

本文深入解析了 JavaScript 中 Promise 的 then/catch/finally 回调如何作为微任务（microtask）严格遵循 FIFO 顺序执行，揭示了看似“异步”的 Promise 实际上完全不打断当前同步流程、所有回调均延迟至本轮宏任务结束后统一调度的本质；同时阐明链式调用是逐级触发微任务而非一次性展开，且 Promise 微任务与 queueMicrotask、MutationObserver 等共享队列但执行顺序受注册时机而非 resolve 时间主导——帮你彻底摆脱“先 resolve 就先执行”的常见误区，掌握真正决定执行次序的关键：回调注册的先后与微任务入队的时序。

当 Promise 被解析（resolve 或 reject）时，其对应的 then、catch、finally 回调会被作为微任务（microtask）推入微任务队列，并在当前宏任务执行结束后、下一个宏任务开始前，按**先进先出（FIFO）顺序**依次执行。

Promise 状态变更触发微任务入队

Promise 构造函数中传入的执行器函数是同步执行的，但其中调用 resolve 或 reject 并不会立即执行后续的 then 回调。它们只是将回调函数注册为微任务，等待当前同步代码执行完毕后统一处理。

• 即使 resolve 是同步调用的，then 回调也一定在本轮宏任务末尾执行，不会打断当前同步流程
• 多个 Promise 链式调用产生的 then/catch 会按注册顺序排队，而非按 resolve 时刻排序
• 同一个 Promise 上多次调用 then，回调按调用顺序入队；不同 Promise 的 then 则按各自 resolve 时间和注册顺序混合入队

微任务队列与 Promise 链的执行节奏

每个 then/catch/finally 返回的新 Promise，其状态确定时又会生成新的微任务。这意味着 Promise 链不是“一次性展开”，而是逐级触发微任务：

• p.then(a).then(b) 中，a 执行完并返回值（或新 Promise）后，才将 b 推入微任务队列
• 如果 a 返回一个已决议的 Promise，b 仍需等待本轮微任务清空后才执行（即进入下一轮微任务）
• reject 后被 catch 捕获，该 catch 回调也是微任务；若 catch 中返回值，后续 then 依然在之后的微任务中执行

与其他微任务的共存关系

Promise 回调和其他微任务（如 queueMicrotask、MutationObserver 回调）共享同一个微任务队列，按插入顺序执行：

• queueMicrotask(fn) 和 Promise.then(fn) 插入的回调，在同一轮微任务阶段中严格按调用先后排队
• 但 Promise 内部实现可能有轻微优先级差异（如 V8 中 Promise 回调略早于 queueMicrotask），不过规范仅保证同类型内 FIFO，跨类型不保证绝对顺序，应避免依赖
• 实践中建议：若需强顺序，统一用 queueMicrotask 或全部走 Promise 链，不要混用并假设执行次序

常见误区提醒

容易误以为“先 resolve 的 Promise，它的 then 就一定先执行”——其实不然：

• let p1 = Promise.resolve(); let p2 = new Promise(r => setTimeout(r, 0)); p1.then(...) 先入队，p2.then(...) 后入队，所以 p1 的回调一定先执行
• 但如果 p1 是异步 resolve（如封装了 setTimeout），而 p2 是同步 resolve，则 p2.then 先注册、先入队，反而先执行
• 关键不在“谁先完成”，而在“谁的 then 先被调用、谁的 resolve 先触发注册”

理论要掌握，实操不能落！以上关于《微任务队列与Promise执行顺序详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！