process.nextTick 优先级最高，它在每个事件循环阶段结束时立即执行，先于 Promise.then 和 setImmediate；适用于需在同步代码结束后、任何异步回调前执行的场景，如防爆栈、错误延时抛出、API 行为对齐。
process.nextTick 的优先级到底有多高
它比 Promise.then 还早，比 setImmediate 和 setTimeout(0) 早两个阶段——不是“快一点”，而是根本不在同一个队列里排队。Node.js 在每个事件循环阶段结束时，会先清空 process.nextTick 队列，再处理 V8 的微任务（比如 Promise），最后才进下一阶段（如 timers、I/O、check）。这意味着：哪怕你在 Promise.then 里调用 process.nextTick，它也会插队到当前阶段末尾，把刚加进来的 Promise 回调挤到下一轮。
什么时候该用 process.nextTick 而不是 Promise 或 setImmediate
核心判断标准是：你是否需要「在同步代码结束后、但任何异步回调开始前」立刻执行一段逻辑？
- 防止递归爆栈：比如自定义 EventEmitter 的
emit方法里触发大量同步监听器，用process.nextTick把后续分发推到栈清空后，避免RangeError: Maximum call stack size exceeded - 错误冒泡控制：在构造函数或初始化阶段捕获同步错误，但又不想立刻抛出（破坏调用者 try/catch 边界），可借
process.nextTick(() => { throw err })延迟到当前帧末尾 - API 行为对齐：某些底层模块（如
fs.read）内部用process.nextTick确保回调总在 I/O 完成后、但不等下一个事件循环周期，保持行为可预测 - 不用
setImmediate：它要等到 check 阶段，中间可能穿插 I/O 回调；也不用Promise.resolve().then()：它被压在 nextTick 后面，多一层延迟
容易踩的坑：nextTick 不是免费的“快进键”
它的高优先级是双刃剑：
- 无限嵌套会饿死事件循环：
process.nextTick(() => process.nextTick(cb))会持续霸占当前阶段末尾，导致定时器、网络请求、甚至setTimeout(0)永远得不到执行 - 与
Promise混用时顺序反直觉：主线程加的Promise.then一定比process.nextTick回调里加的Promise.then先执行，因为微任务队列是“先入先出”，而 nextTick 队列是“先清空再放行” - 浏览器不支持：这是 Node.js 特有 API，写通用库时必须做环境检测或 fallback（比如降级为
Promise.resolve().then()） - 调试困难：V8 的 DevTools 不会把
process.nextTick回调显示在“Microtask”面板里，它被归在更底层的 “Next Tick Queue”，得靠async_hooks或日志打点追踪
一个真实可用的优化模式
常见场景：你封装了一个类，希望用户注册的 onReady 回调在实例完全初始化后、但不阻塞当前同步流程地执行。
class Loader {
constructor() {
this.ready = false;
// 同步初始化
this.initSync();
// 立即通知，但不打断当前调用栈
process.nextTick(() => {
this.ready = true;
if (this.onReadyCb) this.onReadyCb();
});
}
onReady(cb) {
this.onReadyCb = cb;
}
initSync() {
// 比如读配置、建缓存结构……
}
}
这里不用 Promise.resolve().then()，是因为用户可能期望 new Loader().onReady(...) 中的回调在当前函数返回前就已排好队；也不用 setImmediate，因为没必要等 I/O 阶段——ready 状态纯属内存状态变更，process.nextTick 是最贴切的语义匹配。
真正难的是意识到：优先级不是越“高”越好，而是要和你的状态流转节奏对齐。错位的高优先级，比低优先级更容易引发竞态和不可测延迟。
