事件循环是Node.js运行时实现异步非阻塞I/O的核心调度机制，它将异步任务的执行拆分为多个不同的阶段，每个阶段按照固定的顺序依次执行，处理对应类型的任务。I/O回调阶段是事件循环中专门用于处理已完成I/O操作回调函数的环节，是连接底层I/O操作和上层业务逻辑的关键节点。
I/O回调阶段的基本定义
I/O回调阶段是事件循环的第三个阶段，位于timers阶段和idle, prepare阶段之后，poll阶段之前。该阶段的核心作用是执行上一轮事件循环中poll阶段等待到的已完成的I/O操作的回调函数，以及处理一些系统操作相关的回调。
需要注意的是，这里的I/O回调并不包含所有的I/O相关回调，比如setImmediate的回调、关闭事件的回调都不属于该阶段的处理范围，这些回调会在事件循环的其他对应阶段执行。
I/O回调阶段的执行逻辑
事件循环进入I/O回调阶段后，会执行以下操作：
- 检查该阶段对应的回调队列中是否有待执行的回调函数
- 如果有回调函数，按照先进先出的顺序依次执行，直到队列清空或者达到系统设定的单次执行回调数量上限
- 如果队列为空，则直接进入下一个阶段，也就是
idle, prepare阶段
该阶段处理的回调主要包括以下几类：
- 网络I/O操作完成后的回调，比如TCP连接建立、数据接收完成的回调
- 文件I/O操作完成后的回调，比如文件读取、写入操作完成的回调
- 部分系统级别的操作回调，比如底层线程池返回的操作结果回调
代码示例验证I/O回调阶段执行顺序
我们可以通过以下Node.js代码来验证I/O回调阶段的执行时机：
const fs = require('fs');
// timers阶段执行的回调
setTimeout(() => {
console.log('setTimeout callback');
}, 0);
// I/O操作回调，会在I/O回调阶段执行
fs.readFile(__filename, 'utf8', (err, data) => {
if (err) throw err;
console.log('readFile callback');
});
// setImmediate回调，会在check阶段执行
setImmediate(() => {
console.log('setImmediate callback');
});
console.log('main thread code');
上述代码的执行结果通常为：
main thread code setTimeout callback readFile callback setImmediate callback
执行顺序的逻辑是：主线程同步代码先执行，然后进入事件循环的timers阶段执行setTimeout的回调，接着进入I/O回调阶段执行readFile的完成回调，最后进入check阶段执行setImmediate的回调。这也印证了I/O回调阶段在timers阶段之后、check阶段之前的执行位置。
I/O回调阶段和其他阶段的区别
很多开发者容易混淆I/O回调阶段和poll阶段的作用，两者的核心区别如下：
| 对比项 | I/O回调阶段 | poll阶段 |
|---|---|---|
| 核心作用 | 执行已完成的I/O操作回调函数 | 等待新的I/O事件，执行I/O相关的回调（部分场景下） |
| 执行顺序 | 在poll阶段之前 | 在I/O回调阶段之后 |
| 处理队列 | 处理上一轮poll阶段返回的已完成I/O回调 | 处理当前轮次新产生的I/O回调，同时等待新的I/O事件 |
另外，setImmediate的回调属于check阶段，和I/O回调阶段完全独立，即使setImmediate的回调是在I/O回调中注册的，也会等到下一轮事件循环的check阶段才会执行，不会在当前I/O回调阶段执行。
常见误区说明
误区一：所有I/O相关的回调都在I/O回调阶段执行。实际上，只有已经完成且被放入I/O回调队列的回调才会在该阶段执行，新产生的I/O回调如果没有被放入当前阶段的队列，会等到后续轮次的对应阶段执行。
误区二：I/O回调阶段会阻塞等待I/O操作完成。事件循环的I/O回调阶段只处理已经完成的I/O回调，不会主动等待新的I/O操作，等待新I/O操作的任务由poll阶段完成。
理解I/O回调阶段的执行逻辑，能够帮助开发者更准确地判断异步代码的执行顺序，避免在开发中出现异步逻辑不符合预期的问题，尤其是在处理多个I/O操作和定时器混合的场景时，清晰的阶段认知能大幅降低调试成本。