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 阶段是否空闲：

Rydberg Agent Node

使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r

下载

• 若 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 阶段