很多前端同学把 Promise 的状态机背得滚瓜烂熟——pending、fulfilled、rejected张口就来，但一到实际问题就原形毕露：setTimeout和.then()谁先执行？链式then为什么有时输出顺序和直觉完全相反？线上突然冒出来uncaught (in promise)报警，却不知道 Promise 是在哪一步"炸"的。
我最早也吃过这个亏。有次排查一个接口竞态问题，数据一会儿对一会儿错，最后发现根本不是后端返回慢，而是我对 Promise 回调和宏任务、微任务的入场顺序判断错了。这篇文章不打算再抄一遍文档，而是把我自己从"背状态"到"推得出执行顺序"的理解路径完整拆开，结合真实报错场景，把这套机制彻底讲透。适合刚学 Promise 的人建立正确模型，也适合写了两三年 JavaScript 但偶尔还是被事件循环问住的人查漏补缺。
1. 状态、回调和任务队列是三码事：先认清这三点，执行顺序才有解
1.1 pending 是一切起点：Promise 状态机的三条铁律
Promise 的状态确实只有三个：pending（进行中）、fulfilled（已成功）、rejected（已失败）。但如果你只记住这三个词，等于什么都没记住。真正影响代码行为的，是状态流转的三条铁律。
第一，状态只能从pending出发，变成fulfilled或rejected，而且这个变化是单向的、不可逆的。一旦从pending变成fulfilled，你就再也没办法把它掰回pending，也没办法改成rejected。反过来也一样。这个设计很像现实里的订单状态：下单后可以是"已支付"或者"已取消"，但你不可能让一个"已支付"的订单重新变成"待支付"。
第二，resolve()和reject()只是触发状态变化，并不保证状态立即被"消费"。换句话说，Promise 在改变状态的那一刻，只是把挂在它身上的回调"登记"到微任务队列里，回调真正的执行要等当前同步代码跑完。
第三，new Promise((resolve, reject) => {})里的这个函数叫 executor，它是同步执行的。这点非常容易踩坑。很多人以为 Promise 里的一切都是异步的，实际上只有.then()、.catch()、.finally()里的回调才异步，executor 里的代码和你写在外面的普通代码没有任何区别，该同步立刻同步执行。
new Promise((resolve) => { console.log("executor 执行了"); // 同步输出 resolve("成功"); }); console.log("外层同步代码"); // 接着输出 // 执行结果： // executor 执行了 // 外层同步代码这个顺序很多人第一次跑都会被吓到，但理解了"executor 同步、回调异步"之后，Promise 执行机制的地基就算打好了。
1.2 回调注册与回调执行之间隔着一整个事件循环
理解了状态机，下一个必须想明白的问题就是：注册回调和执行回调根本不是一回事。
当你写下promise.then(callback)，你做的只是把callback放进了一个待执行列表。这个列表在 Promise 的机制里就是微任务队列。只有等到当前正在执行的那段代码（也就是主线程的当前宏任务）全部跑完，JavaScript 引擎才会回头来处理这个微任务队列。
很多人理解偏差就出在这里：以为.then()写在哪个位置，回调就在哪个位置执行。实际上.then()的位置只决定了回调和哪个状态绑定，以及它进入微任务队列的先后顺序，真正执行要看事件循环的节奏。
有个生活化的比喻我经常用：主线程执行同步代码就像你在餐厅按菜单顺序上菜，每道菜是一个同步操作。.then()注册回调不是"立刻加菜"，而是服务员在你的订单上记了一笔"等这桌吃完再上甜点"。甜点什么时候上？肯定要等当前这轮服务结束，而且还要排在同样等待的"外带订单"前面。这个"外带订单"就是宏任务。
一旦把"状态变化"和"回调执行"拆成两个独立事件，很多复杂度就迎刃而解：状态是原因，回调执行是结果，中间通过任务队列建立了时序关系。
2. 宏任务是主线剧情，微任务是每集结束后的彩蛋：事件循环调度全拆解
2.1 一个完整 tick：宏任务执行、微任务清空、渲染让位
标题里说"宏任务是主线、微任务是穿插"，这个直觉是对的，但具体机制得再拧紧一圈。
JavaScript 是单线程语言，所有代码都得排队在主线程上跑。你可以把整段程序想象成一部连续剧：宏任务就是正式播出的正片，微任务是每集正片结束后的彩蛋或预告片。但这里有一个关键规则：正片可以有无数个，但每集正片结束、下一集正片开始之前，所有彩蛋必须全部放完，哪怕这期间又冒出来新的彩蛋，也得在这一轮全部放完。
对应到事件循环，一个完整的 tick 是这样走的：
- 从宏任务队列取出一个宏任务执行，比如整段
<script>代码、一个setTimeout回调、一次事件处理函数。 - 这个宏任务执行过程中，凡是
.then()、queueMicrotask()等产生的微任务，全部进入微任务队列。 - 当前宏任务执行完毕，开始清空微任务队列。注意是"清空"，不是"执行一个"。如果微任务里又注册了新的微任务，新微任务也会在这一轮被继续执行，直到微任务队列彻底为空。
- 浏览器视情况决定是否执行一次渲染（render）。
- 回到第 1 步，取下一个宏任务。
截图看代码会更直观：
setTimeout(() => { console.log("宏任务 A"); Promise.resolve().then(() => { console.log("A 产生的微任务"); }); }, 0); setTimeout(() => { console.log("宏任务 B"); }, 0); Promise.resolve().then(() => { console.log("脚本同步段产生的微任务"); });推演一下完整输出：
- 第一个宏任务是整段
<script>。它注册了两个setTimeout（A 和 B），还注册了一个微任务。 <script>执行完，清空微任务队列，输出"脚本同步段产生的微任务"。- 取宏任务 A，输出"宏任务 A"，又注册了一个微任务。A 执行完，清空微任务队列，输出"A 产生的微任务"。
- 取宏任务 B，输出"宏任务 B"。
所以最终顺序是：脚本同步段产生的微任务 → 宏任务 A → A 产生的微任务 → 宏任务 B。这个顺序就是事件循环的真实呼吸节奏。
2.2 产生宏任务和微任务的 API 清单与"优先级"错觉
做执行顺序题的时候，先判断一个操作属于宏任务还是微任务，题目就做对了一半。
浏览器环境里，常见的宏任务来源：
<script>整体代码setTimeout/setInterval- I/O 事件、UI 交互事件
MessageChannelpostMessage（了解即可）
常见的微任务来源：
Promise.then/catch/finallyqueueMicrotask()MutationObserver
Node.js 环境里还要额外注意process.nextTick，它的优先级比 Promise 微任务更高，会在当前阶段结束后立刻执行。这就经常造成一种"明明nextTick写在后面，却先执行"的现象。
我见过不少人把Promise.resolve().then()当成"异步执行"，把setTimeout(fn, 0)也当成"异步执行"，然后以为两者差不多。实际上它们根本不在一个优先级：每轮宏任务结束后必然先清空微任务，因此微任务永远抢在下一个宏任务前面。就算setTimeout(fn, 0)的延时是 0，也要等当前宏任务执行完、清空微任务队列，然后才能轮到它。
3. 七道题把 Promise 输出顺序练成肌肉记忆：完整的逐步推演
这块是我最想写的部分。做 Promise 执行顺序题，光看答案没用，得练出"看到代码脑子里能跑起事件循环"的能力。我挑了七道由浅入深的题，每道都给出完整的推演过程。
3.1 第一组：setTimeout 与 Promise.then 的起跑线
入门题，但能筛掉一批基础不牢的人：
console.log(1); setTimeout(() => { console.log(2); }, 0); new Promise((resolve) => { console.log(3); resolve(4); }).then((value) => { console.log(value); }); console.log(5);逐步推演：
- 同步代码开始执行，
console.log(1)输出1。 - 遇到
setTimeout，把它丢进宏任务队列，继续往下走。 - 进入
new Promise，executor 同步执行，输出3；resolve(4)把 promise 变成fulfilled，于是.then回调进入微任务队列。 console.log(5)输出5。- 当前宏任务（
<script>）结束，清空微任务队列，输出4。 - 宏任务队列里的
setTimeout执行，输出2。
最终输出：1 3 5 4 2。
这道题的价值在于：console.log(3)和resolve(4)发生在同步阶段，但.then回调要等同步代码全部结束后才能执行。很多人以为 Promise 内部全是异步，这是第一个要纠正的错觉。
3.2 第二组：链式 then、catch 的状态传递
看链式then的时候，脑子里要始终记得一点：每次.then()或.catch()都会返回一个全新的 Promise。新 Promise 的状态取决于回调的返回值或是否抛错。
Promise.resolve("成功") .then((res) => { console.log("then1:", res); throw new Error("出错了"); }) .catch((err) => { console.log("catch1:", err.message); return "恢复"; }) .then((res) => { console.log("then2:", res); });推演：
Promise.resolve("成功")直接得到一个fulfilled的 promise。then1回调进入微任务队列。执行时输出then1: 成功，然后throw new Error。这个 throw 让then1返回的 Promise 变成rejected。.catch捕获了上一个 Promise 的rejected，进入微任务队列执行，输出catch1: 出错了，并return "恢复"。返回普通值让catch返回的 Promise 变成fulfilled。- 最后的
.then收到这个fulfilled，输出then2: 恢复。
最终输出：then1: 成功→catch1: 出错了→then2: 恢复。
这个例子说明：catch不一定让整条链"结束"，它只是把状态从rejected又掰回了fulfilled。所以"catch 之后还能不能 then"这个问题，答案是能，而且很常用。
3.3 第三组：微任务排队时，新产生的任务怎么处理
这组题是真正的分水岭。很多人知道要"清空微任务队列"，但不知道"清空"意味着执行过程中新加入的微任务也会被一起执行完。
setTimeout(() => { console.log("timeout1"); Promise.resolve().then(() => { console.log("micro1"); }); }, 0); setTimeout(() => { console.log("timeout2"); }, 0); Promise.resolve().then(() => { console.log("micro2"); });推演：
<script>宏任务执行，注册两个setTimeout，注册一个微任务micro2。<script>结束，清空微任务队列，输出micro2。- 取宏任务
timeout1，输出timeout1，执行中又注册了微任务micro1。 timeout1执行完，清空微任务队列，输出micro1。注意，这轮清空必须等micro1执行完才算完，而不是"清一个就跑去取下一个宏任务"。- 取宏任务
timeout2，输出timeout2。
最终输出：micro2→timeout1→micro1→timeout2。
很多人会写成micro2→timeout1→timeout2→micro1，就是没理解"清空"是彻底清空。微任务队列只要还有任务，下一个宏任务就没有机会上场。
再看一道更考验队列感的题：
Promise.resolve() .then(() => { console.log("a"); setTimeout(() => { console.log("b"); }, 0); }) .then(() => { console.log("c"); }); setTimeout(() => { console.log("d"); }, 0);推演：
- 同步阶段：注册一个
setTimeout(d)，.then链上的第一个回调进入微任务队列。 - 清空微任务队列：第一个
.then执行，输出a，同时注册了setTimeout(b)。这个回调执行完，它返回的 Promise 变成fulfilled，于是第二个.then回调在当前这轮清空中继续被取出执行，输出c。 - 微任务清空，进入宏任务阶段。宏任务队列里有两个任务：
d是先注册的，b是后注册的，所以先输出d，再输出b。
最终输出：a→c→d→b。
这道题的关键是理解"链式 then 的第二个回调也是微任务，而且有可能和第一个回调在同一轮清空中执行"。因为第一个.then执行完立刻让新 Promise 变为fulfilled，第二个.then就顺势被推入当前微任务队列尾部，然后被这轮"清空"顺带处理掉。
再加一道带async/await的综合题，考察 await 的语义：
async function foo() { console.log("a"); await bar(); console.log("b"); } async function bar() { console.log("c"); return "d"; } console.log("e"); foo(); console.log("f");推演：
- 同步代码输出
e。 - 调用
foo()，foo内部同步执行到await bar()之前，输出a。 - 执行
bar()，bar内部同步输出c，返回一个已fulfilled(值为 "d") 的 Promise。 await会把foo中后续代码console.log("b")包装成微任务，然后让出主线程。- 回到全局同步代码，输出
f。 - 微任务阶段，执行
console.log("b")，输出b。
最终输出：e→a→c→f→b。
这道题如果对async/await不熟，极容易写成e a c b f。记住一条：await的右边会先同步执行完，await的左边（后续代码）会在微任务里恢复执行。
4. 热搜报错复盘：unhandled rejection 和 uncaught in promise 的真实现场
掌握了执行机制之后，再回头看那些高频报错，会清楚很多。很多报错不是语法问题，而是异步时机和状态管理的问题。
4.1 "listener indicated an asynchronous response"：异步监听器的响应承诺超时
这个报错在浏览器扩展开发里特别常见。完整的报错一般是类似：
Uncaught (in promise) Error: A listener indicated an asynchronous response by returning a Promise, but the message channel closed before a response was received.
拆开看就清晰了。浏览器扩展的chrome.runtime.onMessage.addListener支持回调函数返回 Promise 来进行异步响应，浏览器会等这个 Promise 落定后再把响应回传。但如果监听器返回了一个 Promise，而消息通道在 Promise 落定之前就关闭了（比如页面跳转、扩展重新加载、没有调用sendResponse也没返回 Promise），就会出现这个错误。
这本质上就是"Promise 状态还没到终点，外部上下文已经没了"。我在处理这类问题时的经验是：
- 如果监听器不需要异步响应，就明确返回
undefined，不要随手返回 Promise。 - 如果必须异步响应，确保在 Promise
.then()里调用sendResponse，并且函数末尾return true保持通道开启。 - 监听器内部所有异步分支都要有
catch，否则某个分支抛出 rejected Promise，就会变成unhandled rejection。
这个报错的排查思路放到普通前端项目里同样适用：只要你在"生命周期可能提前结束"的地方（比如页面卸载、组件销毁）使用了 Promise，就要考虑通道关闭与 Promise 落定之间的竞态。
4.2 "insertBefore 失败"和 cannot read properties of undefined：异步回调里的失效引用
热搜词里还有一条很典型的 DOM 报错：
Uncaught (in promise) NotFoundError: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.
这个报错出现在 Promise 回调里，往往不是因为insertBefore本身写错了，而是异步回调执行时，DOM 已经被更新过了。
举个我实际遇到过的场景：列表加载完成之后，往某个容器里插入新节点。代码大概是这样的：
fetchData().then((data) => { const placeholder = document.getElementById("placeholder"); container.insertBefore(newNode, placeholder); });如果在这段代码执行之前，有其他逻辑因为状态变化重新渲染了整个列表，旧的placeholder节点已经被移动或删除，那么insertBefore就会报"参考节点不是此节点的子节点"。
这类问题的根治思路是：不要在异步回调里持有"历史 DOM 引用"，重新查询节点，或者保证渲染逻辑和异步插入逻辑走同一个数据流。把 DOM 操作收敛到渲染函数里，用状态驱动，而不是在 Promise 回调里直接操作某个"可能已过期"的节点。
类似的还有cannot read properties of undefined (reading ...)，这个更常见：接口返回的数据结构和预期不一致，或者响应还没回来就试图读数据。比如：
fetchData().then((res) => { console.log(res.data.list[0].name); // res.data 或 list 可能是 undefined });这个报错反复出现在热搜里，说明它不是冷门问题。它的本质是：Promise 成功不代表数据结构符合预期。网络请求能返回 200，不代表返回体里的字段都齐全。所以判断一个接口返回正确性的标准，不能只看 Promise 变成fulfilled，还要做结构校验。
4.3 三查法：状态、队列、业界的实战排障套路
把上面这些报错归纳一下，我总结了一个"三查法"，遇到 Promise 相关的诡异报错按顺序排查，基本能覆盖大部分场景。
第一查状态：找出报错的 Promise 是在哪个环节变rejected的。可以用catch临时打日志，或者通过unhandledrejection事件拿到详细的 rejection 对象，打印它的 stack。看到 stack 的瞬间，80% 的问题都能定位到具体代码行。
第二查队列：确认回调执行的时机是否被事件循环延后。如果报错涉及 DOM 过期、全局变量被改写，想想 Promise 回调执行之前，是不是有其他异步任务已经改变了现场。这也是"时序 bug"的高发区域。
第三查生命周期：排查 Promise 的调用链是不是跨了组件、页面、甚至扩展消息通道等有明确生命周期的上下文。一旦上下文关闭，Promise 回调再努力也没用。
说到unhandled rejection，我还想多说一句。它和uncaught exception不一样，它发生在 Promise 的状态变成rejected之后，却没有任何catch或then的 rejected 分支来处理这个状态。浏览器等了一段时间发现这个 Promise 的 rejected 状态没人认领，就在全局抛出一个unhandledrejection事件。Node.js 环境下就是unhandledRejection进程事件。
实际项目里最容易产生这个问题的场景是"忘记 return Promise"。比如：
function doSomething() { fetchData().then((res) => { // 处理数据 }); // 没有 return } doSomething(); // 如果 doSomething 内部没人 catch，rejected 就会变成 unhandled rejection这里的根子是fetchData()产生的 Promise 在doSomething里被"丢弃"了，外层无法感知它的失败。所以我在团队里会强制要求：函数内部创建 Promise，要么 return 出去，要么在内部终结。
5. 从执行机制反推编码规范：让 Promise 代码更稳的几条个人实操建议
理解了执行机制，不转化成编码习惯有点亏。下面这几条都是我在项目里踩过坑之后逐步沉淀下来的实操经验。
5.1 禁止"裸奔" Promise：链尾兜底 + 全局监听
我见过很多事故，根源就是某个 Promise 没有兜底catch，失败后静默吞掉，或者等到用户报障才发现。我的习惯是两条腿走路。
第一，业务代码里凡是新建 Promise 链，必须在链尾留一个catch。哪怕只是打日志也要留。不能因为"这个接口不太会失败"就不写，线上什么事情都可能发生。
第二，在应用入口加全局兜底监听。浏览器环境：
window.addEventListener("unhandledrejection", (event) => { console.warn("未处理的 Promise 拒绝:", event.reason); event.preventDefault(); // 阻止默认的错误输出，视团队规范决定用不用 });Node.js 环境：
process.on("unhandledRejection", (reason, promise) => { console.error("Unhandled Rejection at:", promise, "reason:", reason); });这样即使有遗漏，也能第一时间在日志系统里看到，而不是等用户来投诉。
5.2 await 不是同步：竞态与悬挂请求的处理
用async/await写代码会让人产生一种"这就是同步代码"的错觉，但执行机制里它仍然是微任务调度。最常见的两个坑：
第一个是竞态。多个异步请求并发时，最后返回的不一定是最先发起的，如果直接用返回值覆盖状态，就会出现"旧响应覆盖新响应"。处理方案有很多，我推荐在业务层维护一个递增的请求序号，响应回来时比对序号，或者直接用AbortController取消过期请求。
const controller = new AbortController(); fetchData({ signal: controller.signal }); // 切换参数或组件卸载时： controller.abort();用AbortController还有一个额外好处：请求被取消后，fetch 返回的 Promise 会变成rejected，不会悬挂在队列里浪费资源。悬挂请求是最隐蔽的资源泄漏方式之一，你以为没影响，其实 Promises 队列里堆了一堆"永不落定"的任务。
第二个是await让出了执行权。在await之后的代码，本质是微任务回调。如果在await之后依赖某些外部变量，而这些变量可能在微任务执行前被其他代码修改，就会产生奇怪的结果。这种问题很难靠调试看出来，最好就是减少异步边界上的共享可变状态，把状态变化收敛到单一数据流里。
5.3 复杂异步流的"翻译"套路：链式转 async/await 时的注意点
最后分享一个我重构代码时常用的"翻译"套路。把链式then改成async/await不是单纯的语法替换，而是要做三件事：
第一，把原来的.then((value) => {})改成let value = await promise，这一步等价。 第二，把.catch((err) => {})改成try { ... } catch (err) { ... }。但要注意：try/catch的捕获范围和.catch不一样。.catch只捕获它之前那条链上的 rejected，try/catch会捕获整个try块里所有同步和异步的错误。转换时要确认错误边界没有变化。 第三，把中间产生的新 Promise 单独拆出来。比如：
// 转换前 fetchData() .then((res) => process(res)) .then((result) => save(result)) .catch((err) => log(err)); // 转换后 let res; let result; try { res = await fetchData(); result = await process(res); await save(result); } catch (err) { log(err); }这种写法可读性更好，但执行机制本身没有变化：await之间依然是微任务在调度。千万不要以为await就是把异步变成了同步，它只是让代码长得像同步而已。
理清 Promise 的执行机制，本质上就是弄清楚三件事：状态什么时候变、回调什么时候入队、队列什么时候被清空。这三件事搞明白了，绝大多数 Promise 相关的执行顺序题和线上诡异报错，都能顺着事件循环推出来。我自己在项目里维持的习惯是：每写一个 Promise 链，都会在脑子里跑一遍它的执行时间线——如果某项操作的时序依赖隐式前提，就顺手加注释或者直接重构，别让后来的人靠猜。
