setimmediate 总在 poll 阶段彻底清空后、下一轮 timers 前的 check 阶段执行，严格排队不插队；所有 setimmediate 回调同属一个队列，每轮最多执行一个，优先级低于 process.nexttick 和 promise 微任务。
setImmediate 的执行时机在复杂异步依赖链中不是靠“猜”，而是由 Node.js 事件循环的 check 阶段严格决定的——它不抢跑、不插队，只等 poll 阶段彻底清空后才执行。
它总在 I/O 回调之后、下一轮 timers 之前
当一个文件读取（fs.readFile）、网络请求（http.get）或任何底层 Libuv I/O 操作完成时，其回调会进入 poll 阶段执行。只要这个阶段还在处理回调（包括嵌套的 setTimeout、Promise.then 等），setImmediate 就一直排队等待。只有 poll 阶段确认“没活了”（比如没有待处理的 I/O 回调、也没有活跃的定时器需要检查），事件循环才会推进到 check 阶段，此时所有已注册的 setImmediate 回调才被批量取出并执行。
- 即使你在 I/O 回调里立刻调用 setImmediate，它也不会“马上”运行，而是等到当前 poll 阶段完全退出
- 如果 poll 阶段因有持续 I/O（如长连接、流式读取）而反复循环，setImmediate 就会持续延后，直到 I/O 暂停
- 它和 setTimeout(0) 不同：后者挤在 timers 阶段，可能和前一轮的 setImmediate 交错；而 setImmediate 始终卡在 check 阶段入口
多层嵌套中，它只响应“本轮 poll 结束”信号
常见误区是认为“内层 setImmediate 一定比外层早执行”。实际上，无论嵌套多深，所有 setImmediate 调用都登记到同一个 check 队列，且每轮事件循环最多执行一个（链表结构）。也就是说：
- fs.readFile → callback 内调用 setImmediate(A)，再触发 setTimeout(0, B)，B 进入下一轮 timers 阶段
- 同一 callback 再调用 setImmediate(C)，A 和 C 都排在本轮 check 队列，但 A 先注册就先执行，C 得等下一轮 check
- 如果 A 的执行又触发新的 setImmediate(D)，D 不会插队到本轮，而是加入下一轮 check 队列
与 Promise.then 和 process.nextTick 混用时的优先级锚点
Promise 微任务（then/catch）在当前阶段结束时立即清空；process.nextTick 在更前端，甚至能打断 Promise；而 setImmediate 是三者中唯一必须让出整个 poll 阶段的。因此在混合链中：
- 同步代码 → nextTick 队列 → Promise 微任务 → 当前阶段结束 → 进入 poll → poll 清空 → check（setImmediate 执行）
- 若某次 poll 中触发了 Promise.resolve().then()，该 then 会在 poll 结束前执行完，但不会影响 setImmediate 排队位置
- 错误地在 nextTick 里密集调用 setImmediate，会导致 setImmediate 实际执行被大幅推迟，因为 nextTick 把 poll 阶段“堵”住了
真实依赖链中的典型推演示例
假设一段代码含数据库查询 + 缓存校验 + 日志落盘：
- db.query() 返回 Promise → .then() 处理结果 → 内部调用 cache.get()
- cache.get() 是基于 fs.readFile 的封装 → 其回调里调用 setImmediate(writeLog)
- 同时，主流程还注册了 process.nextTick(updateStatus)
执行顺序固定为：updateStatus（nextTick）→ Promise.then 回调 → fs 回调 → writeLog（setImmediate，在 fs 回调所属 poll 阶段结束后才跑）
