Node.js定时器（setTimeout/setInterval）严格在事件循环timers阶段执行，非“时间到即执行”；其回调仅当事件循环进入timers阶段且满足到期条件时才被取出执行，即使设0ms也需等待下一轮，受poll阶段空闲程度、同步任务阻塞及系统调度影响，存在固有延迟与精度偏差。
Node.js 中定时器（setTimeout、setInterval）的触发不是“时间一到就执行”，而是严格绑定在事件循环的 timers 阶段，其他阶段不会执行它们的回调。
定时器只在 timers 阶段被检查和执行
注册定时器（如 setTimeout(cb, 100)）只是把任务插入 libuv 管理的最小堆，并不立即调度。真正执行必须等到事件循环再次进入 timers 阶段：
- 每次事件循环迭代都从 timers 阶段开始，它会遍历堆中所有已到期的定时器节点
- 满足
当前时间 ≥ 注册时间 + 延迟毫秒数的回调才会被取出并执行 - 即使设置了
0毫秒，也得排队等下一轮 timers 阶段，不会插队到当前同步代码中 - 单次 timers 阶段最多执行有限个回调（libuv 有数量限制），剩余留待下一轮
poll 阶段行为直接影响定时器响应速度
timers 阶段能否“准点”运行，高度依赖 poll 阶段是否空闲：
- 若 poll 阶段无 I/O 事件可处理，且已有到期定时器，libuv 会主动退出阻塞，立刻跳回 timers 阶段——这是实现接近毫秒级响应的关键
- 若 poll 正忙（例如持续处理大量文件读取回调），即使定时器早已到期，也要等 poll 完全结束才轮到 timers
- 长时间同步任务（如 while 循环耗时 3s）会拖慢整个事件循环，导致所有定时器集体延迟
定时器精度受系统与调度机制限制
实际触发时间总存在偏差，原因包括：
- libuv 最小堆不支持 O(1) 到期检测，每次都要遍历过期节点，高并发定时器（数万级）会增加 timers 阶段开销
- CPU 负载高、线程争抢或系统调度延迟，可能带来几毫秒甚至更多抖动
- 极短间隔（如 1ms 连续
setTimeout）可能被 libuv 合并或限频，实际间隔拉长 -
clearTimeout并非立即删除，只是标记 handle 为 closed，后续 timers 阶段跳过该节点
与其他异步 API 的阶段对比
理解定时器需放在整个事件循环上下文中看：
-
process.nextTick：不属于任何阶段，是“本阶段结束后、下一阶段开始前”的插队机会，最快 - Promise 回调（
.then）、queueMicrotask：属于微任务，在每个阶段结束后立即清空 -
setImmediate：在 check 阶段执行，紧接 poll 阶段之后，某些场景下比setTimeout(..., 0)更早 - I/O 回调（如
fs.readFile）：主要在 poll 阶段执行；错误类回调可能落在 pending callbacks 阶段
