根本原因在于Event Loop执行机制和运行时调度约束：setTimeout仅预约执行时机，实际触发需等待主线程空闲、微任务清空及宿主环境检查周期，受同步任务阻塞、后台节流（如Chrome限1000ms）、系统调度等多重延迟影响。
JavaScript 中 setTimeout 延时不精确，根本原因不在定时器本身，而在于 Event Loop 的执行机制和运行时环境的调度约束。
浏览器/Node.js 的定时器只是“预约”，不是“准时闹钟”
调用 setTimeout(fn, 10) 时，宿主环境（如 V8 或浏览器内核）会将该任务加入一个**最小堆（min-heap）或红黑树等高效结构管理的定时器队列**，记录其到期时间。但这个“到期”仅表示“可以执行了”，不表示“立刻执行”。真正能否执行，取决于当前 Event Loop 是否空闲、是否有更高优先级任务在排队。
- 如果主线程正执行一个耗时 50ms 的同步任务，即使 10ms 定时器早已到期，回调也要等到该任务完成、调用栈清空后，才可能被推入宏任务队列
- 浏览器还会对后台标签页主动降频：Chrome 会将
setTimeout最小间隔限制为 1000ms，防止页面在非激活状态持续消耗资源
宏任务队列的插入时机与执行时机存在天然延迟
定时器到期后，其回调函数并不会立即进入宏任务队列，而是由宿主环境在**一次 Event Loop 的检查周期中批量处理**。这个检查不是实时发生的，而是嵌入在每次 Loop 的“宏任务执行完毕 → 微任务清空 → 渲染（浏览器）→ 下一轮宏任务取任务”流程中。
- V8 的
Check阶段（libuv 层）负责轮询定时器队列，但该阶段本身有最小等待时间（如 1ms），且受系统调度影响 - 若前一个宏任务刚结束，Event Loop 正准备取下一个任务，此时定时器刚好到期，它大概率能赶上下一轮；但如果错过这一拍，就得再等至少一次 Loop 周期（通常 > 0.1ms，但实际常为几毫秒）
系统级干扰：线程抢占、节流与精度限制
JavaScript 运行在单线程上，但整个进程仍受操作系统调度影响：
立即学习“Java免费学习笔记（深入）”；
- 操作系统可能因 CPU 负载高、电源策略（如笔记本节能模式）、其他进程抢占等原因，延迟唤醒 JS 线程
- 浏览器渲染帧率（通常 60fps ≈ 16.6ms/frame）会主动对定时器做对齐优化，避免在帧中间触发重排重绘，导致
setTimeout(..., 1)实际延迟接近 4–16ms - Node.js 在
libuv中使用epoll/kqueue/IOCP等机制监听定时器，但底层系统调用（如clock_gettime）本身也有纳秒级误差，且 V8 默认只以毫秒粒度更新时间戳
如何缓解？关键不是“修定时器”，而是换思路
若业务强依赖时间精度（如动画、音频同步、实时协作），不应依赖 setTimeout 或 setInterval 的绝对延时，而应：
- 用
requestAnimationFrame替代短周期定时器（尤其涉及 DOM 更新时），它与屏幕刷新同步，更稳定 - 在回调中读取
performance.now()计算“本该触发的时间点”，再根据偏差动态调整下一次延迟（即自适应补偿） - 对极高精度场景（AudioContext.currentTime 作为高精度时钟源
