JavaScript定时器执行不准确的根本原因在于事件循环调度机制：定时器仅预约任务，实际执行需等待主线程空闲、微任务清空及宏任务队列轮询，受浏览器节流、系统负载和任务队列状态多重影响。
JavaScript 定时器执行时间不“准”，根本原因不在定时器本身，而在于它如何被事件循环调度进任务队列——定时器只是“预约”，真正决定何时执行的，是主线程空闲与否、微任务是否清空、以及宏任务队列的排队状态。
定时器回调不是立即执行，而是进入宏任务队列
当你调用 setTimeout(fn, 10)，浏览器并不是在 10ms 后直接运行 fn，而是把 fn 放入宏任务队列（macrotask queue），等待当前同步代码执行完、所有微任务（如 Promise.then）处理完毕后，事件循环才从宏任务队列中取出它执行。
- 即使 delay 设为 0，也必须等调用栈清空 + 微任务队列清空后才可能执行
- 如果前一个宏任务耗时 50ms，那这个“10ms 定时器”实际可能在 60ms 后才触发
- 多个相同 delay 的定时器，谁先入队、谁先出队，取决于注册顺序和队列调度策略，但不保证严格 FIFO（尤其在高负载或后台标签页下）
浏览器节流与最小延迟限制加剧不确定性
为了节省资源，浏览器对定时器做了硬性约束：
- HTML5 规范规定：连续嵌套定时器或 delay < 4ms 时，自动提升至 4ms（Chrome/Edge），IE 曾为 10ms
- 当页面处于后台标签页，多数浏览器会将 setTimeout/setInterval 节流到最低约 1000ms，导致原本 10ms 的定时器延迟大幅增加
- 系统负载高、内存紧张时，事件循环可能延迟轮询宏任务队列，进一步拉长实际响应时间
任务队列状态直接影响定时器“准时度”
宏任务队列不是独立运行的，它和微任务队列、渲染帧、I/O 任务共享事件循环节奏：
立即学习“Java免费学习笔记（深入）”；
- 一个 Promise 链包含 5 个
.then()，会连续执行完全部微任务，之后才检查宏任务队列——哪怕定时器已到期 - 若某次渲染帧耗时较长（如强制重排重绘），也会推迟宏任务的拾取时机
- setInterval 的回调若执行时间超过间隔值，后续回调不会堆积执行，而是“跳过”或“追赶”，具体行为因浏览器而异
别依赖“精确时间”，而要适应队列调度逻辑
与其对抗非确定性，不如按队列本质设计代码：
- 用
queueMicrotask()替代setTimeout(fn, 0)做轻量级“尽快执行”，它比宏任务更早被调度 - 需要严格顺序？不用多个独立定时器，改用链式调用或 Promise 链显式串行
- 计算密集型任务别卡主线程，移到 Web Worker 中，避免阻塞宏任务队列拾取
- 清理不再需要的定时器（
clearTimeout/clearInterval），防止过期回调干扰队列状态
