setImmediate 在 I/O 回调中总先于 setTimeout(0) 执行，因其回调挂入本轮 Check 阶段，而 setTimeout(0) 被推迟至下一轮 Timers 阶段；事件循环阶段顺序固定为 Timers → Pending I/O → Poll → Check → Close。
setImmediate 在 I/O 回调中总先于 setTimeout(0) 执行，是因为事件循环阶段顺序固定
Node.js 事件循环不是按“谁先注册谁先执行”运行的，而是严格按六个阶段顺序推进：Timers → Pending I/O → Poll → Check → Close。其中：
- setTimeout 的回调在 Timers 阶段执行
- setImmediate 的回调在 Check 阶段执行
- I/O 回调（如 fs.readFile 的回调）本身在 Poll 阶段执行完毕
当 I/O 回调函数体内同时调用 setTimeout(..., 0) 和 setImmediate(...) 时，它们并不会立刻执行，而是被分别挂进对应阶段的任务队列。由于 Poll 阶段结束后，下一个是 Check 阶段（执行 setImmediate），再之后才回到下一轮循环的 Timers 阶段（执行 setTimeout），所以 setImmediate 总是先触发。
关键在于“当前轮次 vs 下一轮次”的调度归属
在 I/O 回调中注册的 setTimeout(..., 0) 并不会挤进本轮 Timers 阶段——因为本轮 Timers 阶段早已过去（它发生在 Poll 阶段之前）。它只能排队等待下一轮事件循环的 Timers 阶段；而 setImmediate 明确属于本轮循环的 Check 阶段，紧随 Poll 之后。
- Poll 阶段执行完 I/O 回调 → 进入 Check 阶段 → setImmediate 立即执行
- Check 阶段结束 → 进入 Close 阶段 → 然后回到下一轮的 Timers 阶段 → setTimeout 才执行
对比主模块中执行顺序不确定的原因
如果把两者写在主模块顶层（非任何回调内）：
- 代码同步执行完后，事件循环进入第一轮 Timers 阶段
- 此时两个回调都已注册，但 setTimeout(0) 的“0ms 到期”依赖系统时钟精度和队列清空速度
- 若 Timers 阶段启动时刚好跨过 0ms 阈值，它就先执行；否则可能让位给后续 Check 阶段
- 因此结果不可靠，不应依赖
这不是设计缺陷，而是有意为之的调度语义
setImmediate 的定位就是“在本次 I/O 处理完成之后、但尚未开始下一轮定时器之前执行”，适合做 I/O 后的轻量级收尾工作（如清理缓存、触发通知）。它比 setTimeout(..., 0) 更贴近 I/O 流程，延迟更低且可预测——只要在 I/O 回调里用，顺序就稳。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
