定时器回调通常比i/o回调更早执行，因事件循环中timers阶段位于poll阶段之前，而绝大多数i/o回调（如fs.readfile）在poll阶段处理；微任务（nexttick、promise）优先级最高，总在各阶段间立即执行。
定时器回调通常比I/O回调更早执行，但这不是“谁优先级更高”的简单比较，而是事件循环阶段顺序决定的——timers阶段在poll阶段之前，而绝大多数I/O回调（如fs.readFile、http请求完成）都落在poll阶段处理。
定时器与I/O在事件循环中的位置
Node.js事件循环按固定顺序遍历多个阶段：
- timers阶段：执行已到期的setTimeout/setInterval回调；
- pending callbacks阶段：处理上一轮遗留的系统级I/O错误回调（如TCP错误）；
- poll阶段：核心I/O处理阶段——检索新事件、执行文件读写、网络响应等回调；
- check阶段：执行setImmediate回调；
- close callbacks阶段：执行socket.close等清理回调。
由于timers在poll之前，一个刚到期的setTimeout(0)回调，会比同一时刻已完成的fs.readFile回调更早进入执行队列——但前提是该I/O回调尚未被poll阶段拾取。若I/O早已完成，它仍需等待下一轮poll阶段才执行。
微任务始终抢占先机
无论timers还是I/O，它们都属于宏任务。而process.nextTick和Promise微任务拥有更高调度权限：
- nextTick队列在当前操作结束后、进入下一事件循环阶段前立即清空；
- Promise.then、async/await后续逻辑也在此时执行；
- 这意味着哪怕在setTimeout回调里抛出Promise，其then也会在下一个宏任务（如下一个setTimeout）之前运行。
实际开发中的典型陷阱与对策
常见误判场景和应对方式：
- 阻塞主线程导致定时器失准：长同步计算（如双重for循环）会拖慢整个事件循环，使setTimeout延迟远超设定值；应将CPU密集任务移至worker_threads或拆分到setImmediate中分片执行。
- I/O回调内setTimeout(0) vs setImmediate：在fs.readFile回调中调用两者，setImmediate几乎总是先于setTimeout(0)执行——因前者进入check阶段，后者要等下一轮timers阶段。
- setInterval内存泄漏风险：未及时clearInterval时，定时器持续注册且无法被GC；推荐用递归setTimeout替代，便于条件控制与资源释放。
- 高优任务被低优I/O阻塞：如定时消息推送被大量日志写入拖慢；可借助Redis有序集合实现优先级队列，由独立worker按分数拉取并执行，绕过事件循环排队瓶颈。
如何选择合适的延时API
根据执行意图选型，而非单纯看“快慢”：
- 需要尽快但不打断当前流程 → 用process.nextTick（慎用，避免饿死其他阶段）；
- 需要在本轮事件循环末尾执行 → 用Promise.resolve().then()；
- 需要在下一轮poll之后、timers之前触发 → 用setImmediate（适合I/O后立即做清理）；
- 需要精确延时或周期执行 → 用setTimeout/setInterval，但接受其非实时性；
- 需要真实时间精度保障 → 避免纯JS定时器，改用系统级调度（如cron服务）或带心跳机制的外部任务队列。
