process.nextTick、Promise、setTimeout 和 setImmediate 的执行顺序如何判断？

简化版

Node.js 中同步代码先执行；当前回调结束后通常先清空 process.nextTick 队列，再处理 Promise 微任务；随后继续事件循环阶段。setTimeout 进入 timers，setImmediate 进入 check，它们谁先执行要看代码所在上下文，尤其要区分顶层代码和 I/O 回调。

详细版

判断顺序题不要死背单一结论，要分层：

先执行当前同步调用栈。
当前回调结束后处理 process.nextTick。
再处理 Promise 微任务。
进入或继续 libuv 事件循环阶段。
setTimeout 看 timers 阶段，setImmediate 看 check 阶段。

在 I/O 回调内部注册时，setImmediate 通常会比 setTimeout(fn, 0) 更早执行，因为 poll 阶段结束后会进入 check 阶段。顶层代码中二者顺序受启动时机、系统调度和 Node 版本影响，不应回答成永远固定。

完整版教学

一、顺序题的第一步永远是同步代码

无论是浏览器还是 Node.js，当前调用栈里的同步代码都先执行。异步 API 的作用通常是注册回调，而不是立刻执行回调。

console.log('A');

setTimeout(() => console.log('timer'), 0);
Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));

console.log('B');

这个例子里，A 和 B 一定先输出，因为它们在当前调用栈中。后面的顺序才需要讨论 nextTick、Promise 和事件循环阶段。

同步阶段: A -> 注册 timer/promise/nextTick -> B
回调边界: nextTick -> Promise -> 后续事件循环阶段

如果面试官给输出题，先把“执行代码”和“登记回调”分开，很多题会立刻清晰。

二、process.nextTick 是 Node 的特殊队列

process.nextTick() 会把回调安排在当前操作结束后尽快执行，并且通常早于 Promise 微任务。它不是 libuv 事件循环的某个阶段，而是 Node 在回到事件循环前额外处理的队列。

Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));
console.log('sync');

常见输出是：

sync
nextTick
promise

为什么要有它？Node 早期需要让 API 可以在当前调用栈结束后、任何 I/O 回调之前做状态修正或错误通知。代价是它优先级很高，如果递归塞入 nextTick，会让事件循环一直没有机会回到 poll 阶段。

三、Promise 微任务也可能造成饥饿

Promise 的 .then()、.catch()、.finally() 回调进入微任务队列。它们在当前同步代码结束后执行，通常晚于 process.nextTick，早于定时器和 I/O 回调。

let n = 0;

function loop() {
  if (++n < 100000) {
    Promise.resolve().then(loop);
  }
}

loop();
setTimeout(() => console.log('timer'), 0);

这段代码会让 timer 明显延后，因为微任务不断补充自己。假设每个微任务只耗时 0.02ms，100000 次也可能累计 2000ms，定时器即使设置为 0，也要等微任务链让出机会。

队列	优先关系	滥用后果
`process.nextTick`	常早于 Promise	饥饿 I/O 和 timer
Promise 微任务	早于宏观阶段回调	延迟 timer 和 I/O
timers	事件循环 timers 阶段	受前面任务耗时影响
check	`setImmediate` 所在阶段	常用于 I/O 后续调度

四、setTimeout 只保证“不早于阈值”

setTimeout(fn, 0) 的 0 不是立即执行，而是告诉运行时“达到最小延迟后，可以在 timers 阶段执行”。如果主线程忙、微任务多、poll 阶段有长回调，它都会延后。

const start = Date.now();

setTimeout(() => {
  console.log(Date.now() - start);
}, 10);

while (Date.now() - start < 100) {}

虽然设置的是 10ms，但输出可能接近 100ms 或更高。因为 JS 主线程被 while 循环占住，事件循环没有机会处理 timers 阶段。

易错点：定时器的时间是“最早可执行时间”，不是“保证执行时间”。面试输出题里看到 0ms 也不能把它放到同步代码后面立刻执行。

五、setImmediate 在 check 阶段，和 I/O 上下文强相关

setImmediate() 的回调在 check 阶段执行。它经常用于“当前 I/O 事件处理完后再执行一段逻辑”。在 I/O 回调中注册 setImmediate 和 setTimeout(0)，通常 immediate 先执行。

import fs from 'node:fs';

fs.readFile('./package.json', () => {
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
});

常见输出是：

immediate
timeout

原因是 fs.readFile 回调处在 I/O 相关阶段，当前 poll 阶段结束后会进入 check 阶段，setImmediate 得到机会；timer 通常要等下一轮 timers。

顶层代码中二者顺序不应说死。不同 Node 版本、启动时机和系统调度都可能影响谁先到期、事件循环先进入哪里。

六、输出题按“位置 + 队列 + 阶段”推理

遇到复杂题，可以画表而不是靠背。先标注每行代码在顶层、timer 回调、I/O 回调还是 promise 回调中；再记录它注册到了哪个队列；最后按当前回调边界清空 nextTick 和微任务，再进入阶段。

1. 执行同步代码
2. 当前回调结束
3. nextTick 队列
4. Promise 微任务队列
5. timers / poll / check / close 等阶段
6. 每个回调结束后重复 3 和 4

一个常见陷阱是“在微任务里继续注册微任务”。新注册的微任务仍可能在同一轮检查中继续执行，导致后面的 timer 一直等。另一个陷阱是“在 I/O 回调里比较 timeout 和 immediate”，这和顶层比较不是同一个问题。

工程上，nextTick 适合做 API 一致性和极短的延后通知；Promise 适合业务异步链；setImmediate 适合把工作让到 I/O 后；setTimeout 适合基于时间的延迟。不要把它们混成一个“异步延迟工具”。

七、常见误区与追问

误区：setTimeout(fn, 0) 就是立刻执行。 0 只是最小延迟，回调还要等调用栈、微任务和事件循环阶段。
误区：setImmediate 永远比 setTimeout(0) 快。 I/O 回调中通常更早，但顶层代码里顺序不应绝对化。
误区：Promise 微任务一定不会阻塞 I/O。 大量递归微任务会持续占用回调边界，让 I/O 和 timer 延迟。
追问：process.nextTick 为什么危险？ 它优先级很高，递归添加会让事件循环无法回到 poll 阶段。
追问：为什么 I/O 回调里 immediate 常先执行？ poll 阶段处理完当前 I/O 后通常进入 check 阶段，setImmediate 正在 check 队列中。
追问：输出题怎么稳定推？ 先同步，再 nextTick，再 Promise，再按所处阶段处理 timers、poll、check，不要只背一个结论。

八、加强记忆

把 Node 调度记成“三层楼”：第一层是当前同步调用栈，第二层是回调边界上的 nextTick 和 Promise，第三层才是 libuv 的 timers、poll、check 等阶段。nextTick 最急，Promise 次之；timeout 看时间阈值，immediate 看 check 阶段；顶层比较留余地，I/O 内比较更稳定。

简化版

详细版