process.nextTick不属于事件循环任何阶段，而是在每个操作结束后立即清空nextTickQueue，优先级高于Promise.then；它由Node.js单独管理，不进入标准微任务队列，JS调用栈一空即执行。
process.nextTick 不属于事件循环的任何阶段，它走的是独立通道——Node.js 在每个操作（哪怕只是一行同步代码）结束后，立刻清空自己的 nextTickQueue，比 Promise.then 还早。
它不排队，它插队
标准微任务（如 Promise.then、queueMicrotask）由 V8 统一管理，在本轮事件循环末尾批量执行；而 process.nextTick 回调被 Node.js 单独放进一个 nextTickQueue，这个队列会在每个事件循环阶段结束前强制清空。比如刚执行完一个 timer 回调，或刚处理完一批 fs.readFile 的 I/O 回调，Node 就会立刻执行所有 pending 的 nextTick，然后才进入 poll 或 check 阶段。
- 即使你在 Promise.resolve().then(() => process.nextTick(...)) 里调用，新回调仍塞进当前阶段的 nextTick 队列尾部，不会等下一轮
- 连续调用 5 次 process.nextTick，它们会串行执行，中间不穿插任何 Promise.then、setImmediate 或 I/O 回调
- 它的优先级不是“排在微任务前面”，而是根本没进微任务队列
看输出顺序最直观
运行这段代码：
console.log('start');
process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));
console.log('end');
立即学习“Java免费学习笔记（深入）”；
输出一定是：start → end → nextTick → promise。
说明：同步代码一结束，nextTick 立刻执行；而 promise 要等到 nextTick 队列彻底清空后，才轮到微任务队列。
和 setImmediate、setTimeout 对比更清楚
setImmediate 属于宏任务，严格绑定 check 阶段，必须等 poll 阶段完全空了才触发；
setTimeout(fn, 0) 进入 timers 队列，要等下一轮事件循环的 timers 阶段。
- nextTick 总在 setImmediate 之前，哪怕 setImmediate 写在前面
- nextTick 也总在 setTimeout(fn, 0) 之前，因为它不等阶段切换，只等当前操作结束
- 这种顺序不是竞态，是 Node.js 事件循环设计决定的硬性规则
名字有误导，本质是“当前 tick 尾部”
Node.js 官方文档明确说：“这个名字有点误导”。它不是延后到下一个事件循环周期，而是抢在当前 tick 结束前做最后干预——JS 调用栈一空，它就执行，不等 I/O、不等定时器、不等渲染。
浏览器没有 process.nextTick，它无法跨平台模拟，纯属 Node.js 特有机制。
