JavaScript定时器仅保证回调不早于设定时间执行，实际触发受事件循环、浏览器降频（后台/嵌套/跟踪脚本）、硬件延迟等多重因素影响，需用performance.now()补偿或改用requestAnimationFrame/Web Worker等替代方案。
JavaScript定时器本身不提供实时保证，它的“延迟”只是下限——回调不会早于设定时间执行，但随时可能晚很多。这种非实时性不是bug，而是事件循环机制与宿主环境协同作用的必然结果。
事件循环决定“何时能执行”，而非“何时该执行”
当你调用 setTimeout(fn, 100)，浏览器只是把 fn 记录进一个内部定时器列表，并承诺：100ms 后把它放进宏任务队列。但真正执行它，要等三件事都完成：
- 当前调用栈完全清空（所有同步代码跑完）
- 本轮所有微任务（如 Promise 回调、
queueMicrotask）全部执行完毕 - 浏览器完成一次渲染（如有必要），再从宏任务队列取出第一个任务
也就是说，即使系统空闲，也至少要跨过“同步 → 微任务 → 渲染 → 宏任务”这一轮流程。如果中间某步耗时波动（比如一次重排重绘花了 20ms），那原本 100ms 的定时器就变成 120ms+ 才触发。
浏览器主动降频：后台、嵌套、跟踪脚本都会被限速
为节省资源和保护用户隐私，浏览器会在多种场景下拉低定时器分辨率：
立即学习“Java免费学习笔记（深入）”；
-
页面切到后台：Chrome/Firefox 把
setTimeout最小间隔强制抬高到 1000ms；部分安卓 Firefox 甚至限制到 15 分钟 -
连续嵌套调用：递归使用
setTimeout超过 5 层（Chrome/Firefox）或 3 层（Edge），最小 delay 就被锁死在 ≥4ms - 识别为分析脚本：Firefox 55+ 对已知 GA、Plausible 等跟踪代码进一步节流，防止后台静默采集
硬件与系统层无法绕过的物理延迟
即使 JS 代码完全空闲，精度仍受底层制约：
- CPU 时间片调度：JS 线程可能刚被分配到 CPU，定时器 tick 就已错过
- 内存访问抖动：GC 触发、缓存未命中或页错误，会带来毫秒级不可预测延迟
- 节能模式：笔记本降频时，
performance.now()的增量也不再均匀，基准本身就漂移了
应对思路：接受偏差，专注补偿与替代
与其纠结“怎么让 setInterval 精确到 ±1ms”，不如转向更可控的模式：
- 用
performance.now()记录真实流逝时间，在回调中动态计算偏移并调整下次 delay - 动画类任务优先用
requestAnimationFrame，它与屏幕刷新节奏对齐，响应更稳定 - 高精度计时（如音频同步、游戏逻辑）移入
Web Worker，避开主线程干扰 - 新 API 如
scheduler.postTask提供更细粒度的任务优先级控制，适合关键路径调度
本质上，JavaScript 定时器的设计目标是“不早于”，不是“恰好”。理解这一点，才能写出鲁棒、可预期的异步逻辑。
