javascript定时器“不准”是单线程与事件循环机制决定的必然现象，其执行时机取决于主线程空闲、微任务清空及浏览器节流状态，而非设定毫秒值。
JavaScript定时器的“不准”不是bug，而是单线程+事件循环模型下的必然结果。它不承诺精确到毫秒的触发，只保证至少延迟指定时间后执行。真正决定执行时机的，是主线程是否空闲、微任务是否清空、以及浏览器是否处于节流状态。
事件循环才是定时器真正的调度者
setTimeout和setInterval注册的回调，并不会在设定时间一到就立刻运行。它们先进入浏览器的“定时器队列”，等待事件循环检查：只有当调用栈（call stack）为空、且所有微任务（如Promise.then）执行完毕后，事件循环才会从宏任务队列中取出下一个定时器回调。
- 如果主线程正执行一个耗时100ms的for循环，哪怕你设了setTimeout(fn, 10)，fn也要等到循环结束+微任务清空后才执行——实际延迟可能达110ms以上
- delay设为0，本质是“尽快排队”，而非“立即执行”，它仍需排在当前同步任务和所有微任务之后
- HTML5规范强制最小延迟为4ms（Chrome/Edge），IE11为10ms；低于该值会被自动向上取整
精度损失的三大现实来源
定时器偏差不是代码写得不好，而是运行环境层层叠加的结果：
- 主线程阻塞：长任务、大量DOM操作、未优化的循环都会让回调“排队等候”，延迟不可控
- 页面可见性节流：标签页切换到后台时，浏览器会将setInterval降频至约1000ms，setTimeout也可能被大幅推迟
- 系统级调度干扰：CPU频率调节、多任务抢占、垃圾回收暂停等底层行为，都会让JS线程暂时失联
requestAnimationFrame才是动画场景的正确选择
如果你需要与屏幕刷新节奏严格同步（比如动画、滚动效果），不要依赖setInterval(16)或setTimeout(..., 16)。requestAnimationFrame由浏览器原生控制，它：
- 自动匹配显示器刷新率（通常60fps ≈ 16.7ms/帧）
- 在页面不可见时自动暂停，不消耗资源
- 保证回调在浏览器下一次重绘前执行，避免布局抖动和丢帧
- 比setInterval更省电、更稳定，是动画开发的事实标准
高精度需求应主动校准，而非依赖固定间隔
对倒计时、节拍器、音视频同步等场景，setInterval的累积漂移会越来越严重。推荐用动态递归+时间戳校准：
- 每次执行后记录真实耗时，计算与预期间隔的偏差
- 下一次setTimeout的delay = 目标间隔 − 当前漂移量
- 这样可把长期误差控制在2ms内，远优于原生setInterval的15ms+偏差
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
