process.nextTick 不在微任务队列中，而是由 Node.js 单独维护 nextTickQueue，在每个事件循环阶段结束前强制清空，优先级高于 Promise.then 和 queueMicrotask，但不属于微任务。

process.nextTick 并不在微任务队列中——它压根不进那个队列。所谓“特殊优先级”，其实是它根本绕开了微任务调度机制，走了一条更底层、更激进的执行通道。

它不排队，它插队

标准微任务（如 Promise.then、MutationObserver）统一由 V8 引擎在本轮事件循环末尾批量清空；而 process.nextTick 回调被 Node.js 单独维护在一个 nextTickQueue 中，这个队列会在每个事件循环阶段结束前强制清空——比如刚执行完一个 timer 回调、或刚处理完一批 I/O 回调后，立刻执行所有 pending 的 nextTick，然后才进入下一阶段（如 poll、check）。

• 哪怕你在 Promise.then 里调用 process.nextTick，新回调也不会等下一轮，而是塞进当前阶段的 nextTick 队列尾部，仍会在本轮该阶段结束时执行
• 连续调用 5 次 process.nextTick，它们会串行执行，中间不穿插任何其他类型回调（包括 Promise.then）
• 它比 Promise.then 快，不是因为“排在微任务前面”，而是因为它根本不和微任务一起排队

看输出顺序最直接

运行这段代码，结果稳定可复现：

Zenlink - Node SDK for ZenHeart

ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。

下载

console.log('start');
process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));
console.log('end');

输出一定是：start → end → nextTick → promise。
这说明：同步代码结束后，nextTick 立刻执行；而 promise 要等到整个阶段（含 nextTick 清空）完成后，才轮到微任务队列。

和 setImmediate 对比更清晰

setImmediate 属于宏任务，安排在 check 阶段，必须等 poll 阶段彻底结束才触发；nextTick 则在 poll 阶段内部的每次回调之后就可能执行。

• 同一轮中，nextTick 总在 setImmediate 之前
• 即使 setImmediate 写在 process.nextTick 前面，执行顺序仍是 nextTick 先
• 这种差异不是竞态，是事件循环阶段设计决定的硬性顺序

别被名字骗了

“nextTick”听起来像“下一个事件循环周期”，其实它发生在当前 tick 的尾部。Node.js 官方文档明确说：“这个名字有点误导”。它不是延后，而是抢在阶段切换前做最后干预。

• 浏览器没有 process.nextTick，它的行为无法跨平台模拟
• 想测试是否真在微任务前执行？加一句 queueMicrotask(() => console.log('micro'))，你会发现它总在 nextTick 之后
• 真正需要“阶段内立即响应”的场景极少，多数时候 Promise.resolve().then 更安全、更标准