nexttick 总是比 setimmediate 先执行：同步代码→nexttick队列→check阶段的setimmediate；nexttick属独立微任务队列，setimmediate属事件循环check阶段，二者均为node.js特有api。
setImmediate 和 process.nextTick 是 Node.js 独有的异步调度机制，浏览器中不存在。它们都用于推迟回调执行，但所处的调度层级完全不同——nextTick 在当前操作结束后立刻执行，setImmediate 则要等到事件循环进入 check 阶段。
执行时机：nextTick 插队，setImmediate 排队
process.nextTick 不属于事件循环的任何阶段，它维护一个独立的微任务队列。只要当前同步代码或当前阶段回调执行完毕，Node.js 就会立即清空 nextTick 队列，不等下一阶段开始。
setImmediate 的回调则被注册到事件循环的 check 阶段。它必须等 poll 阶段（I/O 回调）彻底结束之后，才会被执行。
- nextTick 总是比 setImmediate 先执行
- 同一轮中多次调用 nextTick，所有回调会连续执行，中间不穿插 I/O 或定时器
- setImmediate 每轮事件循环最多执行一个回调（链表结构），适合控制节奏
使用风险：优先级高 ≠ 更安全
nextTick 的高优先级是一把双刃剑。若在递归逻辑中滥用，比如用 nextTick 实现长耗时任务分片，会导致 I/O 回调长期得不到执行，即“事件循环饥饿”。
setImmediate 虽然延迟稍大，但它天然让出 poll 阶段，给网络请求、文件读写等 I/O 操作留出执行机会。
- 避免在 nextTick 中无限递归或密集调用
- 拆分 CPU 密集型任务时，优先选 setImmediate
- 错误传递、状态同步等需“马上但不打断”的场景，适合 nextTick
环境识别：出现这两个 API 就是 Node.js
浏览器事件循环只有宏任务和微任务两层抽象，没有 check 阶段，也不支持 process.nextTick 或 setImmediate。如果一段代码同时用到它们，并讨论执行顺序，基本可以断定运行环境是 Node.js。
前端想模拟类似行为，应使用 Promise.then()（微任务，接近 nextTick 语义）或 setTimeout(fn, 0)（宏任务，更接近 setImmediate 的延迟感）。
- nextTick ≈ 浏览器中 Promise.resolve().then()
- setImmediate ≈ 浏览器中 setTimeout(fn, 0)，但语义更明确：等这一轮 I/O 完了再做
- 两者都不是跨平台 API，不可直接用于前端项目
典型执行顺序验证
以下代码输出固定为：1 → 4 → 2 → 3
console.log('1');
process.nextTick(() => console.log('2'));
setImmediate(() => console.log('3'));
console.log('4');
说明：同步代码（1、4）先执行；接着立刻执行全部 nextTick 回调（2）；最后进入下一轮事件循环的 check 阶段，执行 setImmediate（3）。
不复杂但容易忽略：顺序不是由书写位置决定，而是由它们各自注册的队列在事件循环中的介入点决定。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
