Node.js 中 setImmediate 与 process.nextTick 优先级对比

process.nextTick 优先级高于 setImmediate，它在当前操作结束后立即执行，不属于事件循环任何阶段，而 setImmediate 在下一轮 check 阶段执行；nextTick 可能导致饥饿，应按场景谨慎选用。

在 Node.js 的事件循环中，process.nextTick 的执行优先级高于 setImmediate —— 它们虽都用于“延迟执行”，但触发时机和所处的阶段完全不同。

执行时机差异：nextTick 属于当前操作的“末尾”，setImmediate 属于下一轮事件循环的“开始”

Node.js 事件循环分为多个阶段（timers、pending callbacks、idle/prepare、poll、check、close callbacks）。process.nextTick 不属于任何阶段，而是在**当前操作完成之后、进入下一个事件循环阶段之前立即执行**；而 setImmediate 被放入 **check 阶段**，即 poll 阶段结束后才运行，属于真正意义上的“下一轮事件循环的早期”。

• 一个同步操作后调用 nextTick，回调会紧随其后执行（哪怕中间穿插了 I/O 或 timer）
• setImmediate 的回调一定等到当前事件循环彻底结束、新循环启动并走到 check 阶段时才执行
• 即使在 timer 阶段内调用 setImmediate，它也不会在本轮 timers 后立刻执行，而是等 poll → check

嵌套调用时 nextTick 会“饿死” setImmediate

如果大量递归调用 process.nextTick（如未设退出条件），事件循环将无法进入下一阶段，导致 setImmediate、setTimeout、I/O 回调全部被阻塞 —— 这是典型的“饥饿问题”。而 setImmediate 每次只调度一次，天然受事件循环节制，不会造成这种风险。

• nextTick 回调内部再调用 nextTick，会不断堆积在 nextTick 队列，持续执行直到队列清空
• setImmediate 回调即使再次调用 setImmediate，也只会为下一轮 check 阶段添加一项，不会抢占当前控制权
• 因此，不建议用 nextTick 实现轮询或递归任务，应优先考虑 setImmediate 或 queueMicrotask（更现代的微任务替代）

与 Promise.then 的关系：nextTick 和微任务同级但早于 setImmediate

Promise.then 回调属于微任务（microtask），与 process.nextTick 同属“当前操作结束后立即执行”的范畴，但 Node.js 中 nextTick 的优先级略高于 Promise 微任务（即 nextTick 回调总在 Promise.then 之前执行）；而 setImmediate 是宏任务（macrotask），排在所有微任务之后、下一轮事件循环 check 阶段。

• 执行顺序典型示例：nextTick → Promise.then → setTimeout(0) / setImmediate
• 注意：浏览器中没有 nextTick，且 Promise.then 和 setTimeout(0) 的相对顺序与 Node.js 不同，不可跨环境假设
• 若需跨平台一致的微任务调度，推荐使用 queueMicrotask()（Node.js 11+ / 浏览器支持）

实际使用建议：按目的选，而非“谁更快”

不要因为 nextTick “更快”就滥用。它的设计初衷是让开发者在当前操作收尾前插入清理或错误处理逻辑（例如在 EventEmitter emit 后立即响应异常），而不是做通用延迟。

• 需要确保在当前操作完全结束后、其他异步逻辑介入前执行 → 用 process.nextTick
• 需要“等这一轮事件循环结束，再执行”（比如避免阻塞 poll 阶段）→ 用 setImmediate
• 需要兼容性好、语义清晰的微任务 → 优先用 queueMicrotask
• 普通延迟（如 0ms 等待）→ 更推荐 setTimeout(fn, 0)，语义明确且行为稳定