setimmediate总在事件循环的check阶段执行，位于poll阶段之后、close callbacks之前；在i/o回调中调用时几乎总先于settimeout(0)执行，因其紧随poll阶段末尾；而process.nexttick优先级更高，属微任务，不属任何事件循环阶段。
setImmediate 的调度逻辑取决于它被调用的时机和所处的事件循环阶段，核心在于它总被排入 check 阶段，而非 timers 或 poll 阶段。
setImmediate 总在 check 阶段执行
Node.js 事件循环有六个阶段，check 是其中之一，位于 poll 阶段之后、close callbacks 之前。无论 setImmediate 在哪被调用，它的回调都会被放入 check 队列，等待该阶段轮到时执行。
- 如果当前正处于 poll 阶段（例如刚完成一次 I/O 回调），且 poll 队列已空，事件循环会直接进入 check 阶段，此时 setImmediate 回调几乎“立刻”执行。
- 如果 poll 阶段还有任务待处理，或当前处于其他阶段（如 timers），setImmediate 回调需等到下一轮循环的 check 阶段才执行。
在 I/O 回调中调用时优先级更高
当 setImmediate 出现在 fs.readFile、net.socket 等 I/O 操作的回调函数内时，它几乎总是比同为 0 毫秒的 setTimeout 先执行。
- 原因：I/O 回调属于 poll 阶段的末尾，紧接着就是 check 阶段；而 setTimeout(0) 属于 timers 阶段，要等下一轮循环才可能触发。
- 这种确定性使 setImmediate 成为 I/O 完成后“紧接着做点什么”的可靠选择，比如清理资源、触发下一步流程。
与 process.nextTick 的关键区别
process.nextTick 不属于事件循环任何阶段，它在当前操作完成、但尚未退出当前阶段前执行，优先级高于所有阶段回调。
- nextTick 是 microtask，setImmediate 是 macrotask（check 阶段）。
- 同一轮中：nextTick → 所有同步代码结束 → setImmediate → 下一阶段（如 timers）。
- 因此 nextTick 总比 setImmediate 更早执行，哪怕它们写在同一行代码里。
不保证绝对顺序，但行为可预测
单独调用 setImmediate 和 setTimeout(0) 时，执行顺序可能因启动时机、系统负载略有浮动；但在 I/O 回调内部，顺序是稳定的。
- 避免依赖“谁先谁后”的模糊场景，应按语义选 API：需要紧接当前操作之后 → 用 nextTick；需要在 I/O 后、但不抢占主线程 → 用 setImmediate；需要延后到下一轮开头 → 用 setTimeout(0)。
- 现代 Node.js（v12+）中，setImmediate 已非必需，Promise.then + queueMicrotask 可覆盖多数场景，但它在 I/O 后调度仍具语义清晰性。
