node.js定时器（settimeout、setinterval）的回调仅在事件循环timers阶段执行，依赖libuv最小堆管理到期检查，受poll阶段行为、同步任务阻塞及系统精度限制影响，不保证绝对准时。
Node.js定时器（setTimeout、setInterval）的触发不是“到点就执行”，而是受 Event Loop 的 timers 阶段 严格控制——它只在该阶段被轮询检查并执行，且执行时机还受 poll 阶段行为影响。
timers 阶段是定时器回调的唯一执行入口
Event Loop 每次循环都会进入 timers 阶段，检查是否有已到期的定时器。只有在这个阶段，才会从最小堆（libuv 实现）中取出所有 已过期且未执行 的定时器回调，并按顺序执行（不保证绝对精确，但尽可能快）。
- 定时器注册（如
setTimeout(cb, 50)）只是把任务插入 libuv 的最小堆，不立即调度 - 真正执行必须等到事件循环再次抵达 timers 阶段
- 若 timers 阶段队列中有大量回调，Node.js 会限制单次执行数量，剩余留待下一轮
poll 阶段可能“提前唤醒”timers 阶段
当 poll 阶段空闲（无 I/O 事件可处理）且存在已到期定时器时，libuv 会主动退出 poll 阻塞，立刻跳回 timers 阶段——这是定时器能“准点”响应的关键机制。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 例如：无 I/O 操作时，
setTimeout(cb, 100)往往在 ~100ms 后很快执行 - 但若 poll 阶段正忙（如持续处理文件读取回调），即使定时器已到期，也要等 poll 结束才进 timers
- 系统级调度延迟（CPU 负载、线程争抢）也可能造成几毫秒偏差
定时器精度与实际行为的常见误区
很多人误以为 setTimeout(cb, 0) 会“立刻执行”，其实它仍要排队等 timers 阶段；而 setImmediate 因在 check 阶段执行，在某些场景下反而比 0ms 定时器更快。
-
setTimeout(fn, 0)→ 进入 timers 堆，最早在下一轮 timers 阶段执行（通常比 setImmediate 慢） -
setImmediate(fn)→ 进入 check 阶段队列，紧接 poll 阶段后执行 - 连续多次
setTimeout若间隔极短（如 1ms），libuv 可能合并或限频，实际间隔大于设定值
底层依赖 libuv 的最小堆管理
libuv 用最小堆组织所有活跃定时器，根节点永远是最近到期的那个。这种结构支持高效插入、更新和提取，但不提供 O(1) 到期检测——每次 timers 阶段都要遍历堆中过期节点。
- 堆操作由 C 层完成，JS 层不可见，但直接影响性能边界
- 大量定时器（如数万个）会增加 timers 阶段开销，建议用时间轮等方案优化
-
clearTimeout实际是标记 handle 为 closed，后续 timers 阶段跳过该节点
