定时器是“最小延迟触发器”而非“倒计时器”，其回调仅保证不早于设定时间执行，实际触发受事件循环、浏览器节流、系统调度等多重延迟影响；应以 performance.now() 锚定时间并动态补偿，或用 requestAnimationFrame、Web Worker 优化精度与响应。
定时器不是“倒计时器”，而是“最小延迟触发器”
很多人误以为 setTimeout(fn, 100) 表示“100ms 后准时执行”，其实它只承诺：回调不会早于 100ms 触发，但可能晚得多。这是由 JavaScript 的事件循环机制决定的——定时器回调被推入宏任务队列，必须等当前调用栈清空、所有微任务（如 Promise.then）执行完后，才有机会被执行。
这意味着：若主线程正忙于渲染、计算或处理大量 DOM 操作，哪怕只多占用了 20ms，原本该在 100ms 执行的回调，实际可能在 125ms 甚至更晚才运行。
浏览器强制施加的硬性精度天花板
不同场景下，浏览器会主动拉低定时器分辨率，这不是 bug，而是设计策略：
- 4ms 下限规则：连续嵌套调用（如递归 setTimeout）达 5 层以上时，Chrome/Firefox 会将 delay 强制提升至 ≥4ms；Safari 是第 6 层，Edge 更激进（第 3 层）
-
后台标签节流：页面切到后台时，Chrome 和 Firefox 会把所有
setTimeout/setInterval的最小间隔拉高至 1000ms（即 1 秒），部分安卓版 Firefox 甚至延长至 15 分钟 - 跟踪脚本额外限制：Firefox 55+ 对已识别的分析类脚本（如 GA）进一步降频，防止后台静默采集
硬件与系统层的真实拖累来源
即使 JS 代码完全空闲，精度仍受限于底层：
立即学习“Java免费学习笔记（深入）”；
- CPU 调度粒度：操作系统以“时间片”分配 CPU，JS 线程可能刚被调度出去，就错过一个定时器 tick
- 内存访问抖动：DRAM 访问延迟在 30–100ns，但 GC 触发、页错误（page fault）或缓存未命中可带来毫秒级延迟
-
节能模式干扰：笔记本省电状态下，CPU 频率动态降低，系统定时器基准漂移，导致
Date.now()或performance.now()的增量也不再均匀
比“修精度”更重要的是“控偏差”
与其执着于让 setInterval 精确到 ±1ms，不如接受误差并主动补偿。常见有效路径：
-
用
performance.now()做时间锚点：每次回调中记录实际执行时刻，与理论时刻对比，动态调整下次 delay（例如本次晚了 8ms，下次 delay 就设为 interval − 8） -
用
requestAnimationFrame替代高频 UI 定时器：它绑定屏幕刷新节奏（通常 60fps ≈ 16.6ms），不受 tab 失活影响，且能自动匹配设备能力 -
复杂逻辑移出主线程：通过 Web Worker 执行耗时计算或轮询，再用
postMessage通知主线程更新视图，避免阻塞定时器调度
