setImmediate 任务独立于定时器队列，专属于事件循环的 check 阶段，由 libuv 维护的 immediate_queue 双向链表管理，与基于最小堆的 timers 队列物理隔离、逻辑独立。
在 Node.js 环境中，setImmediate 的任务并不进入“定时器队列”，也不会与 setTimeout 的队列发生转换。它有自己独立的调度位置——事件循环的 check 阶段队列，和定时器阶段（timers phase）完全分离。
setImmediate 专属 check 阶段，不参与定时器队列
setImmediate 回调被插入到事件循环的 check 阶段任务队列中，这个队列由 libuv 维护，与 timers 队列物理隔离、逻辑独立。Node.js 源码中，setImmediate 创建的 Immediate 实例会被链入一个双向链表（immediate_queue），由事件循环在 check 阶段主动遍历执行，不会被挪到 timers 堆或做任何队列转换。
定时器队列（timers queue）则基于最小堆实现，只管理 setTimeout/setInterval 的到期判断。即使你传入 0，Node.js 内部也会将其修正为 1ms（源码中 after = 1），并按时间顺序排队——这和 setImmediate 的“下一 check 阶段”语义本质不同。
两者不会互相转换，但执行顺序受事件循环启动时机影响
在顶层代码中直接调用：
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
-
setTimeout(fn, 0)→ 进入 timers 队列，等待当前 loop 轮次是否已过 1ms -
setImmediate(fn)→ 进入 immediate 链表，等待下一个 check 阶段
由于事件循环启动时的系统时间精度、loop 初始化耗时等微小差异，可能出现 setTimeout 先触发（timers 阶段恰好已满足 1ms）或 setImmediate 先触发（timers 阶段跳过，直接进入 poll → check）。这不是队列转换，而是两个独立队列在不同阶段被轮询的自然结果。
I/O 回调中调用时，顺序才真正确定
一旦进入 I/O 回调（如 fs.readFile 的回调），执行顺序就稳定了：
- 当前 poll 阶段结束后，立刻进入 check 阶段 →
setImmediate执行 - 而
setTimeout(0)属于下一轮 timers 阶段 → 必然晚于本轮 check
所以，在 I/O 完成后需“尽快响应”的场景（如流式处理、中间件钩子），setImmediate 是明确优于 setTimeout(0) 的选择，不是靠队列转换，而是靠事件循环阶段的硬性约定。
替代方案更推荐 Promise 或 queueMicrotask
由于 setImmediate 仅限 Node.js、且 check 阶段行为在跨平台或未来版本中可能调整，现代开发中：
- 若需微任务级调度，用
queueMicrotask（浏览器 & Node.js v11+ 支持） - 若需宏任务级但可移植，用
Promise.resolve().then()模拟 next tick 后的异步边界 - 避免依赖
setImmediate与setTimeout(0)的相对顺序
