mongoose.connect返回的Promise的then回调为何晚于setTimeout执行？

核心误区澄清 #

你混淆了两个完全独立的逻辑：

• Promise.prototype.then 回调本身的调度优先级：已经被决议（fulfilled/rejected）的Promise的then回调，确实属于微任务，优先级高于setTimeout等宏任务
• Promise的决议时机：只有当Promise从pending状态转为已决议状态时，对应的then回调才会被加入微任务队列等待调度；如果Promise一直处于pending状态，then回调不会进入任何队列

执行时序拆解 #

结合Node.js事件循环的阶段规则，你的代码执行顺序完全符合预期：

1. 同步代码执行阶段
   依次执行：打印START、调用mongoose.connect发起MongoDB连接请求（返回pending状态的Promise，连接对应的网络IO逻辑被注册到IO回调队列）、注册setTimeout回调到timers队列、注册两个已决议的Promise的then回调到微任务队列、打印END。
2. 微任务队列清空阶段
   同步代码执行完成后，优先清空当前所有微任务：
   • 执行第一个Promise的then回调：sleep 1s后打印1. Resolved Promise: A
   • 执行第二个Promise的then回调：sleep 1s后打印2. Resolved Promise: B
     整个阶段耗时2s，此时setTimeout(0)（Node.js中会被强制转为至少1ms的延迟）已经完全到期，等待timers阶段调度。
3. 下一轮事件循环阶段
   Node.js事件循环的阶段执行顺序为：timers阶段（处理到期的setTimeout/setInterval回调） → pending callbacks阶段（处理网络/文件等IO回调） → 其他阶段：
   • 首先进入timers阶段，执行到期的setTimeout回调，打印setTimeout() - callback queue
   • 之后进入pending callbacks阶段，处理MongoDB连接成功的IO回调，此时才会resolvemongoose.connect返回的Promise，将对应的then回调加入微任务队列
   • 清空当前微任务队列，执行connect的then回调，打印Connected to MongoDB

验证方法 #

你可以把两个Promise的sleep时长改为10ms，大幅缩短微任务执行耗时，就会看到MongoDB连接的then回调大概率会排在setTimeout前面，此时因为微任务很快执行完成，timers阶段的setTimeout还没到最小延迟阈值，事件循环会先进入poll阶段等待IO回调，连接成功后直接决议Promise执行then回调。

内容的提问来源于stack exchange，提问作者Iggy