Node.js事件循环：I/O回调内调度setImmediate会重算I/O通知超时吗？

核心机制前提 #

先把 poll 阶段最容易被误解的运行规则说透：poll 阶段的等待超时参数，只在每次进入 poll 阶段的入口节点做一次统一计算，整个阶段跑起来之后，不会中途打断现有流程、回头重算超时值。
我们之前提到的三种超时设置规则（存在待执行 setImmediate 任务则超时设为0、存在到期定时器则按剩余时间计算超时、无约束则无限阻塞），全都是入口处的一次性判断，不是边执行回调边实时更新的动态值。

问题1：I/O 回调中新增 setImmediate/setTimeout 任务时，超时会立刻重算吗？ #

答案是不会立刻重算。
当最开始进入 poll 时，因为没有前置的 setImmediate 任务、也没有到期的定时器，超时被设为无限大。后续在任何一个 I/O 回调的执行过程中，哪怕你调用 setImmediate() 或 setTimeout() 新增了调度任务，这些新任务只会被写到对应阶段的任务队列里，根本不会触发当前正在运行的 poll 流程中断、回头重新调整超时参数。
只有等当前这一轮 poll 阶段完全跑完，下一轮事件循环迭代重新走到 poll 入口的时候，这些新增的任务才会被纳入新的超时计算逻辑里。

问题2：回调 A 内新增 setImmediate 任务 C，回调 B 和 C 谁先执行？ #

实际执行顺序是 B 先于 C 运行，完整流程可以一步步拆解：

• 刚进 poll 阶段时，因为没有前置的 setImmediate、定时器任务，超时设为无限大，队列里已经排着待执行的回调 B，同时等待两个异步操作的完成通知。
• 第一个 I/O 通知到达，对应的回调 A 被加入待执行队列，poll 按顺序开始执行 A。A 执行过程中调用 setImmediate() 把 C 塞进 check 阶段的任务队列——这步只是入队，不会立刻打断当前流程跳去执行 C。
• A 的所有同步代码跑完之后，poll 不会停下来去 check 阶段找 C，反而会继续把当前队列里剩下的待执行任务跑完，也就是紧接着执行 B。
• 等 poll 队列里所有待执行的 I/O 回调全部清空之后，事件循环才会判断下一个要走的阶段：这时候发现 check 阶段已经有入队的任务 C，就会切入 check 阶段执行 C。

常见认知误区 #

很多人看到 setImmediate 名字带“immediate”，就以为它是能立刻插队执行的高优先级任务，实际上它的调度优先级永远低于“当前 poll 队列里已经存在的待执行 I/O 回调”——哪怕是执行 I/O 回调的过程中新加的 setImmediate 任务，都得等当前队列里的存量 I/O 回调全部跑完，才有机会被调度。

补充：如果 poll 队列彻底空了，既没有新的 I/O 事件待处理，也没有待执行的 setImmediate、定时器任务，poll 才会回到无限阻塞等待新 I/O 通知的状态。

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