JavaScript定时器“不准”的根源在于其本质是最小延迟触发器而非精确倒计时，受事件循环调度、主线程空闲状态及浏览器/系统节流共同影响。
JavaScript 定时器的“不准”，根源不在代码写法，而在于它本质是最小延迟触发器，不是倒计时钟表。单线程只是表象，真正起决定作用的是事件循环如何调度、主线程是否空闲、以及浏览器和系统层层叠加的节流与延迟。
定时器回调必须排队等三件事做完
- 当前同步任务执行完毕（比如一个耗时 80ms 的 for 循环）
- 所有微任务清空（Promise.then、queueMicrotask 等）
- 浏览器完成本次渲染（layout & paint）
只有这时，事件循环才会从宏任务队列里取出你的 setTimeout 回调——哪怕你设的是 setTimeout(fn, 1)，实际执行也可能晚于 100ms。
浏览器会主动“降频”以保性能
立即学习“Java免费学习笔记（深入）”；
- 标签页切到后台时，
setInterval会被强制拉长到约 1000ms，setTimeout同样大幅推迟 - HTML5 规范规定：嵌套调用超过 5 层后，最小延迟升至 4ms（Chrome/Edge），IE11 是 10ms
- 移动端或低功耗设备还会进一步放宽限制，比如省电模式下定时器响应变慢
系统级干扰无法绕过
- CPU 动态调频、垃圾回收暂停、操作系统的线程调度粒度（Windows 通常 15ms，Linux 可达 1ms）都会让 JS 线程短暂失联
- 这些不是 bug，而是运行环境的客观现实
高精度场景不能靠“设固定间隔”硬扛
-
setInterval的误差会逐次累积，100 次后可能漂移几百毫秒 - 正确做法是用
performance.now()锚定真实时间，每次执行后计算偏差，动态调整下次延迟 - 动画类任务直接换
requestAnimationFrame，它由浏览器原生控制，自动对齐刷新节奏，不可见时自动暂停，不丢帧、不耗电
不复杂但容易忽略
