JavaScript定时器嵌套误差源于浏览器对连续setTimeout的节流机制，深度超5层时强制最小延迟4ms（前台）或1000ms（后台），叠加回调耗时导致任务堆积与雪球效应；动态校准需用performance.now()计算真实流逝时间并动态调整下次延迟，高精度场景推荐requestAnimationFrame、Web Worker或服务端时间锚点。
JavaScript 中定时器嵌套本身不会直接“导致”误差累积，真正起作用的是连续调用 setTimeout 形成的链式调度模式，而浏览器对这类高频嵌套有强制节流机制——这才是误差累积的物理根源。
嵌套定时器触发 4ms 最小延迟限制
HTML5 规范明确要求：当 setTimeout 调用嵌套深度超过 5 层（即连续五次 setTimeout 套 setTimeout），浏览器必须将后续延迟值自动提升至至少 4ms。即使你写的是 setTimeout(fn, 1)，实际执行间隔也会被拉长。
- 这不是 bug，而是浏览器为防止 CPU 过载做的主动干预
- Chrome、Firefox 在前台标签页中普遍执行该限制；后台标签页则更激进——最小延迟升至 1000ms
- 误差从第一次调整就开始偏移，后续每次叠加，形成“越调越慢”的雪球效应
回调执行耗时引发的延迟漂移
嵌套定时器常用于手动模拟 setInterval 行为（比如倒计时校准），但如果单次回调执行时间 > 设定间隔，就会出现“任务堆积”。例如：
- 设定每 100ms 执行一次，但某次 DOM 更新+计算耗时 180ms
- 下一轮 setTimeout 实际在 180ms 后才被注册，理论应 200ms 触发，结果变成 380ms
- 误差不重置、不补偿，下下轮继续基于错误时间点计算 → 累积放大
动态校准是应对累积误差的核心手段
不依赖固定 delay，而是每次运行时用 performance.now() 测量真实流逝时间，再反推下次该等多久：
立即学习“Java免费学习笔记（深入）”；
- 记录初始基准时间
startTime = performance.now() - 每次回调中计算已过时间：
elapsed = performance.now() - startTime - 若目标是每 1000ms 执行一次，则第 n 次理想时间为
startTime + n * 1000 - 下一次延迟设为：
nextDelay = Math.max(0, 1000 - (elapsed % 1000)) - 用
setTimeout而非setInterval，避免按“上次启动时刻”而非“理想时刻”计时
更稳定的替代方案
对精度敏感场景（如音视频同步、游戏帧逻辑），纯 setTimeout 嵌套不是最优解：
- requestAnimationFrame：适合与屏幕刷新节奏对齐的任务，误差控制在 ~16ms 内，且后台自动暂停
- Web Worker：把计时逻辑移出主线程，完全规避渲染/脚本阻塞影响
- 服务端时间锚点：倒计时类应用应以服务器返回的时间戳为唯一可信源，客户端仅做差值渲染
