NodeJS中setTimeout与setImmediate执行顺序变化的原因解析

示例代码 #

console.log("START");

setImmediate(() => {
  console.log("setImmediate 1");
});

setTimeout(() => {
  console.log("setTimeout 1");
}, 0);

Promise.resolve("hello").then((obj) => console.log("Promise 1"));

console.log("END");

两种输出情况 #

大多数场景下的输出：

START
END
Promise 1
setTimeout 1
setImmediate 1

偶尔出现的输出：

START
END
Promise 1
setImmediate 1
setTimeout 1

背后的逻辑解释 #

• Node.js的事件循环分为多个固定阶段，核心相关的是定时器阶段（timers）、轮询阶段（poll）、检查阶段（check），执行顺序是定时器→轮询→检查。
• setTimeout(fn, 0)的实际最小延迟并非0毫秒，Node.js会将其默认设置为1毫秒（具体值依赖系统定时器精度），它的回调会被安排在定时器阶段执行。
• setImmediate的回调固定在检查阶段执行，这个阶段紧跟在轮询阶段之后。
• 同步代码执行完毕后，会先清空微任务队列（比如Promise的then回调），所以Promise 1的输出顺序永远在同步代码之后、所有宏任务之前。
• 关键变量在于同步代码执行完的时机：
  • 如果同步代码执行耗时稍长，结束时已经超过了setTimeout的1毫秒延迟，事件循环会先进入定时器阶段执行setTimeout回调，之后再到检查阶段执行setImmediate，这就是多数情况下的顺序。
  • 如果同步代码执行得极快，结束时还没到setTimeout的延迟时间，事件循环会先进入轮询阶段等待。等定时器延迟到期后，轮询阶段结束，会直接进入检查阶段执行setImmediate，下一轮事件循环才会处理定时器阶段的setTimeout回调，这就导致了顺序反转。

简单总结：两者的执行顺序取决于同步代码结束后，系统定时器是否已经触发了setTimeout的延迟，而setTimeout(0)的实际延迟受系统精度和当前线程状态影响，因此会出现两种不同的执行结果。

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