要理解 await，首先需要明确几个核心要点：await 并非简单地“暂停函数”，而是将后续代码封装为微任务，添加到当前宏任务的末尾进行排队。这一机制是理解 async/await 行为的关键。

await 触发的微任务：究竟何时入队？

当代码执行到 await promise 时，JavaScript 引擎的处理逻辑非常清晰，主要分为两种情况：

• 如果 promise 的状态已经 settled（fulfilled 或 rejected），引擎会立即将 await 后面的语句（即 async 函数中接下来的代码）包装成一个微任务，直接加入微任务队列。需要特别注意的是，这里的“立即”指的是在当前宏任务执行期间。
• 如果 promise 仍处于 pending 状态，则引擎会先挂起这个 async 函数，等到 promise 状态变更后，再将后续逻辑作为微任务入队。
• 这里有一个容易被忽视的细节：这个微任务在当前宏任务结束前就已入队，但它的实际执行要等到当前宏任务彻底完成、控制权交还给事件循环之后。

严格来说，“入队”动作发生的时机，正是理解调度顺序的关键所在。

await 和 Promise.then，究竟谁的优先级更高？

事实上，await 后续代码与 Promise.prototype.then 回调都属于微任务，它们进入的是同一个微任务队列，遵循先进先出（FIFO）的原则。

• 举个例子：await Promise.resolve(); console.log('a'); 和 Promise.resolve().then(() => console.log('b')) 中，'a' 和 'b' 的打印顺序完全取决于谁先入队。
• 通常来说，在同一个宏任务中，await 后续代码一定比 then 回调更早入队。因为 await 表达式求值在前，等它触发微任务入队时，后面的 then 可能还未执行到。
• 但如果 then 是在 await 暂停期间被 resolve 触发（例如异步 resolve），则它可能更早入队，从而改变执行顺序。

因此，不必再纠结于“谁优先级更高”，理解“谁先入队”才是问题的本质。

await 挂起，为何不阻塞事件循环？

当 async 函数遇到 await 时，它会返回一个 pending 状态的 Promise，并立即让出线程。当前宏任务继续向下执行或结束，不会因为 await 而卡住。

• 后续代码不会同步执行，也不会占用调用栈。
• 引擎会记录 async 函数的上下文（例如变量环境、执行点），等到对应 promise settle 后，再通过该上下文恢复执行。
• 这也正是 async/await 能够优雅地避免回调地狱，同时保持非阻塞特性的原因所在。

常见误区：await 不等于 setTimeout(0)

很多人会将 await 与 setTimeout(fn, 0) 混为一谈，但它们的调度机制完全不同：

• setTimeout(fn, 0) 推送的是宏任务，而 await 推送的是微任务。
• 微任务总在当前宏任务结束前被全部清空，而宏任务要等到下一轮事件循环。
• 因此，await Promise.resolve(); console.log('micro'); 一定早于 setTimeout(() => console.log('macro'), 0); 打印。
• 即使 Promise 是同步 resolve 的，await 后的代码也要等到本轮宏任务结束，但它的执行时间仍然在 setTimeout 之前。

理解 await 的微任务调度，核心在于看清它如何与事件循环协作——并非简单的“等待”，而是“安排好后续工作，稍后执行”。