process.nextTick 不是微任务，它在每个事件循环阶段结束后立即执行，优先于 Promise.then 等微任务；其回调存于 Node.js 独立队列，不经过 V8 微任务调度，本质是当前 tick 尾部的“最后干预机会”。
process.nextTick 不是微任务，也不在微任务队列里——它走的是 Node.js 自己的一条“快车道”。它的特殊优先级，本质是“不排队、只插队”：每次事件循环阶段结束前，Node.js 会强制清空 nextTick 队列，且这个动作发生在微任务（如 Promise.then）之前。
它根本不在微任务队列中
很多人误以为 process.nextTick 是“最高优先级的微任务”，这是常见误解。实际上：
- V8 引擎维护标准微任务队列（Promise.then、queueMicrotask、MutationObserver），由引擎在本轮宏任务结束后统一执行；
- 而 process.nextTick 回调被 Node.js 运行时单独存入一个内部队列（nextTickQueue），完全绕开 V8 的微任务调度机制；
- 这个队列不是“排在微任务前面”，而是“根本不和微任务一起排”。它在每个事件循环阶段（如 timers、poll、check）执行完回调后立刻清空，早于微任务队列的触发时机。
执行时机比 Promise.then 更早
看这段代码就能直观验证：
console.log('start');
process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));
console.log('end');
立即学习“Java免费学习笔记（深入）”；
输出顺序恒为：start → end → nextTick → promise。这说明：
- 同步代码（start、end）先执行完毕；
- 接着立即执行所有 pending 的 nextTick 回调；
- 等 nextTick 队列彻底清空后，才轮到 V8 执行微任务队列里的 Promise.then。
它比 setImmediate 和 setTimeout(0) 快得多
setImmediate 属于宏任务，安排在 check 阶段；setTimeout(0) 归属 timers 阶段。而 process.nextTick 可以在 poll 阶段内部的任意 I/O 回调之后就执行，甚至在同一个阶段内连续触发多次：
- 哪怕你在 Promise.then 里调用 process.nextTick，新回调仍塞进当前阶段的 nextTick 队列尾部，本轮就会执行；
- 连续调用 5 次 process.nextTick，它们会串行执行，中间不会插入任何其他类型回调（包括 Promise.then 或 I/O）；
- 即使 setImmediate 写在 process.nextTick 前面，执行顺序仍是 nextTick 先——这不是竞态，是事件循环阶段设计决定的硬性顺序。
别被名字误导：“nextTick”其实发生在当前 tick 尾部
Node.js 官方文档明确指出：“这个名字有点误导”。它并不表示“下一个事件循环周期”，而是指“当前操作完成后的下一个执行点”。你可以把它理解为：
- 同步代码执行完后、但还没进入下一事件循环阶段前的“最后干预机会”；
- 常用于错误透传、资源清理、API 一致性处理（比如让异步方法的错误在同步上下文中抛出）；
- 滥用会导致事件循环“饿死”其他阶段（如 I/O 或定时器），所以应谨慎使用，避免无限递归调用。
