事件循环定时器不追求毫秒级精确，而是保证至少延迟指定时间后执行；其偏差源于单线程调度、timers阶段触发时机、系统精度、CPU负载、GC暂停及主线程阻塞等多层延迟；周期性任务易累积误差；高精度场景应基于时间戳校准或使用RAF/nextTick+Worker等替代方案。
事件循环驱动的定时器，本质上不追求“毫秒级精确”，而是保证“至少延迟指定时间后执行”。它的偏差不是缺陷，而是单线程调度模型下的自然结果。
定时器只在特定阶段被检查
无论是浏览器还是 Node.js，定时器回调都必须等到事件循环进入 timers 阶段（浏览器中对应宏任务队列的消费）才能被取出并执行。这个阶段不会随时触发，而是受整个循环节奏控制：
- 注册 setTimeout(cb, 10) 只是把任务放进最小堆，不立即安排执行
- 即使 10ms 到了，若当前正执行长同步任务或微任务未清空，回调就得排队等待
- Node.js 中，poll 阶段空闲时会主动唤醒 timers 阶段；但若 poll 正忙于 I/O，timers 就得等它结束
系统与运行时层层叠加延迟
从代码到实际执行，中间经过多个环节，每层都可能引入不可忽略的偏差：
- 操作系统 timer 分辨率：Linux 的 setitimer、Windows 的 WaitForMultipleObjectsEx 默认精度约 10–15ms
- CPU 负载升高：75% 以上负载下，10ms 定时器平均延迟可跳到 50ms 以上
- V8 GC 暂停：Full GC 触发 Stop-The-World，事件循环冻结，定时器回调直接卡住 100ms 甚至更久
- 主线程阻塞：一个 50ms 的 for 循环，会让所有在此期间到期的定时器全部顺延执行
周期性任务更容易累积误差
setInterval 不是“每隔 N 毫秒准时触发一次”，而是“上一次回调开始后，再等 N 毫秒”。如果回调本身耗时 8ms，间隔设为 10ms，那实际周期就变成 18ms，并越滚越大：
- 连续多次 setTimeout(…, 1) 可能被 libuv 合并或限频，实际间隔远大于 1ms
- 浏览器在非活跃标签页中会将最小延迟提至 1000ms，彻底打乱节奏
- QTimer、ReactPHP Timer 等同类机制也遵循相同逻辑——它们依赖事件循环分发，不是独立硬件计时
更可控的替代思路
与其对抗机制，不如适配机制。高精度需求场景下，应放弃“固定 delay”，转向基于真实时间戳的主动校准：
- 用 performance.now() 获取高精度起始时间，每次回调内计算已过时间，动态决定下次延迟
- 高频轮询类任务（如心跳、采样）改用 requestAnimationFrame（前端）或 process.nextTick + 自循环（Node.js）做微调
- CPU 密集操作务必移出主线程：Node.js 用 worker_threads，浏览器用 Web Worker
- 服务间时间对齐靠授时协议（如 NTP），而非本地定时器同步
