setImmediate、setTimeout与nextTick执行顺序差异疑问

核心疑问 #

事件循环以阶段为单位运行，且首次进入的是定时器阶段，那为什么设置延迟为0的setTimeout有时不会先执行？按道理它应该在事件循环首次进入定时器阶段时就已到期。

第一个示例：执行顺序不稳定的原因 #

代码示例 #

setTimeout(() => {
    console.log('timeout');
}, 0);

setImmediate(() => {
    console.log('immediate');
});

运行结果 #

两次运行可能得到两种顺序：

timeout
immediate

或

immediate
timeout

原因解析 #

Node.js对setTimeout的最小延迟做了限制：即使你写了0，实际会被修正为1ms（这是受系统内核定时器的精度限制）。而执行顺序的不确定性，取决于脚本执行完成后，首次进入定时器阶段时是否已经过了这1ms：

• 如果脚本启动后，同步代码执行耗时极短（比如仅几微秒），此时1ms还没到，定时器阶段不会触发setTimeout的回调，事件循环会直接进入**检查阶段（check phase）**执行setImmediate的回调，等到下一轮事件循环才会执行setTimeout。
• 如果脚本执行时因为系统调度、资源占用等原因，耗时刚好超过了1ms，那首次进入定时器阶段时，setTimeout的回调已经到期，就会先执行它，再执行后续阶段的setImmediate。

第二个示例：执行顺序固定的原因 #

代码示例 #

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

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

process.nextTick(() => {
  console.log("Nexttick");
});

console.log("Hello");

运行结果 #

多次运行始终输出：

Hello
Nexttick
Timeout
Immediate

原因解析 #

这里的关键是process.nextTick的特性：它不属于事件循环的任何阶段，而是在当前操作完成后、事件循环进入下一个阶段前立即执行。具体执行流程如下：

1. 先同步执行最外层的console.log("Hello")。
2. 执行process.nextTick的回调，输出Nexttick。
3. 此时进入事件循环的第一个阶段——定时器阶段，经过同步代码+nextTick的执行，耗时肯定已经超过了1ms的阈值，setTimeout的回调已经到期，因此会被执行，输出Timeout。
4. 事件循环继续推进到检查阶段，执行setImmediate的回调，输出Immediate。

正是process.nextTick的执行给了足够的时间让setTimeout的1ms延迟到期，所以这个顺序是固定的。

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