node.js定时器按事件循环timers阶段顺序执行，并非抢占i/o，其真实位置在poll阶段之前；需避免用settimeout(0)模拟异步，应结合setimmediate或worker_threads优化调度。
Node.js 中定时器不是用来“抢”I/O 执行权的，而是按事件循环阶段顺序参与调度的工具。理解它在非阻塞 I/O 循环中的定位，比盲目调用 setTimeout(0) 更关键。
定时器在事件循环中的真实位置
定时器回调（setTimeout、setInterval）只在 timers 阶段 执行，这个阶段排在 poll（I/O 主处理阶段）之前。但要注意：这不等于“定时器优先级高于 I/O”。它只是阶段靠前；而 I/O 回调是否已就绪、是否已被 poll 阶段拾取，才决定实际执行先后。
- 刚到期的
setTimeout(0)，若 I/O 还未完成或尚未进入 poll 阶段，它大概率先执行； - 若文件读取早已完成，只是还没轮到 poll 阶段处理，那该
fs.readFile回调会等下一轮 poll，反而落在定时器之后； - 所有定时器都维护在一个最小堆中，按到期时间排序，事件循环只在 timers 阶段批量检查并执行已到期项。
避免用定时器“模拟异步”的常见误区
开发者有时用 setTimeout(fn, 0) 把同步逻辑“推后”，以为能释放主线程——但这只是让回调排队进下一个 timers 阶段，并不能绕过当前同步阻塞。
- 长耗时计算（如大数组遍历、JSON 解析）仍会卡住整个事件循环，导致后续所有定时器和 I/O 回调延迟；
- 在 I/O 回调里写
setTimeout(fn, 0)，往往不如直接用setImmediate(fn)—— 因为后者进 check 阶段，紧接 poll 之后，通常比下一轮 timers 更快； -
process.nextTick()比两者都早，在当前操作结束、进入下一阶段前立即清空队列，适合错误传递或紧急状态同步，但滥用会饿死其他阶段。
面向真实场景的定时器使用策略
定时器的价值不在“精确触发”，而在“可控节奏”。结合非阻塞 I/O 特性，可构建更稳健的任务流。
-
替代 setInterval 做周期任务：用递归
setTimeout替代setInterval，每次在上一次任务完成后才设下一次，避免堆积或丢失； -
给 I/O 操作加超时保护：用
Promise.race([fs.readFile(...), timeout(5000)])包裹异步 I/O，防止慢盘或网络卡死拖垮服务； -
错峰调度高开销 I/O：对日志写入、监控上报等非实时 I/O，用
setImmediate或带随机抖动的setTimeout分散到不同 tick，缓解 poll 阶段压力； - 不依赖绝对精度，设计容错逻辑：比如心跳检测设为 30s 定时器，但服务端接受 45s 内的心跳包，留出事件循环抖动余量。
当定时器与 I/O 协同失效时的兜底思路
如果发现定时消息推送总被大量文件写入延迟，说明 poll 阶段持续满载，timers 阶段虽靠前却等不到执行机会。这时不应优化定时器参数，而应跳出事件循环：
- 将高优任务（如通知、告警）移出主线程，用
worker_threads独立运行； - 借助 Redis 有序集合 + 后台 worker，把“何时执行”交给存储层排序，Node.js 只负责拉取和投递；
- 对必须同步响应的请求，用
process.nextTick快速返回 ACK，再异步落库，把耗时部分彻底解耦。
