Node.js定时器回调并非立即执行，而是等待事件循环进入timers阶段时批量处理；执行顺序取决于当前所处阶段、微任务清空时机及nextTick/setImmediate等特殊队列的优先级。
定时器触发后，Node.js不会立刻执行回调，而是等当前阶段结束、进入timers阶段时统一处理。真正影响后续任务执行顺序的，是事件循环所处的阶段、微任务清空时机，以及nextTick、setImmediate等特殊队列的位置。
定时器回调不是“到点就跑”，而是排队等轮到它
setTimeout或setInterval的回调被加入timer queue，但只有当事件循环进入timers阶段时才会批量执行。即使设为0毫秒，也要等当前同步代码和本轮微任务完成，再等下一轮循环到达timers阶段。
- 多个setTimeout(0)按注册顺序依次执行，不保证绝对精确时间，只保证在timers阶段内顺序执行
- 如果当前处于poll阶段且队列为空、没有待处理I/O，Node可能快速跳过poll，直接进timers阶段；但如果poll正在等待I/O，就会先阻塞，延迟timers执行
- 定时器精度受系统调度和事件循环负载影响，高负载下可能明显滞后
每个阶段结束后，都会清空微任务队列
这是决定“Promise.then”“queueMicrotask”等行为的关键。微任务不属任何阶段，而是在每个宏任务阶段结束时立即执行，且会清空整个队列。
- 比如在timers阶段执行完所有定时器回调后，立刻执行所有已排队的Promise.then
- 若某个Promise.then里又创建了新Promise，其then也会被加入当前微任务队列，本轮一并执行（即“递归清空”）
- 这和浏览器一致，但Node中nextTick队列优先级更高——它会在当前操作刚结束、任何阶段开始前就执行
nextTick、setImmediate与定时器的执行层级不同
它们不在同一维度竞争，而是分布在事件循环的不同“插槽”：
- process.nextTick()：不属事件循环阶段，而是在当前操作返回前强制插入，优先级最高。常用于错误边界处理或避免阻塞
- setImmediate()：排在poll阶段之后、check阶段执行，适合“等I/O做完再干点别的”场景
- setTimeout(fn, 0)：仍属timers阶段，受定时器堆管理，实际执行时机取决于上一轮是否刚过poll、是否有活跃I/O等
实际执行顺序由进入事件循环的时机决定
同一个setTimeout(0)和setImmediate()，谁先执行并不绝对——取决于代码运行时事件循环所处的阶段。
- 若代码在I/O回调中执行（如fs.readFile回调），此时刚离开poll阶段，接下来会进check阶段 → setImmediate先于setTimeout执行
- 若代码在主模块同步执行，事件循环尚未进入poll，会先进timers → setTimeout先执行
- 因此不能依赖二者固定顺序，需按语义选择：紧急响应用nextTick，I/O后置用setImmediate，延时调度用setTimeout
