Node.js中Check Queue与IO Queue执行顺序为何与预期不符？

你原本认为Node.js中IO Queue的优先级高于Check Queue，但运行以下代码：

fs.readFile('./tweets.json', (err, data) => {
  console.log('IO Queue');
});
setImmediate(() => {
  console.log('Check Queue');
});

输出结果为：

Check Queue
IO Queue

此外，若文件读取出现错误，输出顺序则会反转。这背后的核心是事件循环各阶段的触发逻辑，而非队列优先级的绝对高低，具体分两种情况说明：

文件存在时，Check Queue先执行的逻辑 #

Node.js事件循环的核心阶段顺序为：Timers → Pending Callbacks → Idle/Prepare → Poll → Check → Close Callbacks

代码执行流程：

1. 同步代码阶段：发起fs.readFile异步请求（交由操作系统处理），同时注册setImmediate的Check阶段回调。
2. 同步代码执行完毕，进入事件循环的Poll阶段：
   • 此时操作系统尚未完成文件读取（哪怕文件极小，磁盘IO也需要短暂时间），Poll阶段检测到当前无可用IO回调，就会检查是否有setImmediate回调待执行。
   • 由于存在setImmediate回调，Poll阶段会直接跳转至Check阶段，执行console.log('Check Queue')。
3. 等操作系统完成文件读取后，IO回调会被加入Poll队列，在下一轮事件循环的Poll阶段被执行，输出IO Queue。

文件读取错误时，IO Queue先执行的逻辑 #

如果文件不存在（或读取操作立即触发错误），操作系统会快速返回错误结果：

1. 同步代码发起fs.readFile请求后，操作系统很快将错误结果返回给Node.js，对应的IO回调被加入Poll队列。
2. 同步代码执行完毕进入事件循环，走到Poll阶段时，检测到Poll队列中有等待执行的IO回调，优先执行该回调，输出IO Queue。
3. Poll队列执行完毕后，检测到存在setImmediate回调，再进入Check阶段执行，输出Check Queue。

总结：IO回调的执行时机完全取决于异步IO操作的完成时间——若在事件循环进入Poll阶段前完成，IO回调会先执行；若未完成，Poll阶段会优先跳至Check阶段执行setImmediate回调。

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