JavaScript定时器不保证准时执行，其回调仅承诺“至少延迟指定时间后入宏任务队列”，实际执行受事件循环、主线程阻塞、浏览器节流等影响；应基于时间戳校准或使用requestAnimationFrame提升精度。
JavaScript 中定时器（setTimeout、setInterval）不是“准时”的，它们的回调进入宏任务队列后，需等待当前执行栈清空、且轮到该宏任务时才执行——这期间可能被其他宏任务抢占。
定时器触发 ≠ 立即执行
调用 setTimeout(fn, 10) 表示“至少 10ms 后把 fn 推入宏任务队列”，而非“10ms 后立刻运行”。实际执行时间取决于：
- 当前同步代码是否耗时过长（如大循环、复杂计算）
- 是否有更高优先级或更早入队的宏任务正在排队（如 I/O 回调、其他定时器、用户交互事件）
- 浏览器是否节流后台标签页中的定时器（尤其
setTimeout延迟常被拉长至 1000ms）
宏任务队列的执行顺序是先进先出（FIFO）
所有宏任务（包括定时器回调、I/O 回调、setImmediate（Node.js）、UI 渲染后任务等）共用一个队列。例如：
setTimeout(() => console.log('A'), 0);
Promise.resolve().then(() => console.log('B'));
setTimeout(() => console.log('C'), 0);
输出为 B A C：两个 setTimeout 回调依次入宏队列，而 Promise.then 是微任务，插在当前宏任务末尾、下一个宏任务开始前执行。
立即学习“Java免费学习笔记（深入）”；
长任务会显著推迟定时器执行
若主线程正执行一段 50ms 的同步代码，即使设置了 setTimeout(fn, 5)，其回调也至少要等到 50ms 后才进入可执行状态：
- 定时器到期时，仅将回调加入宏任务队列，不中断当前运行
- 浏览器不会“插队”执行宏任务；必须等当前宏任务 + 所有微任务全部完成
- 这意味着“最小延迟”只是下限，不是保证值
避免依赖定时器精度的实践建议
对时间敏感的逻辑（如动画帧、倒计时显示、心跳检测），应采用更可靠的方式：
- 动画使用
requestAnimationFrame，它与屏幕刷新率同步，且不会被宏任务阻塞 - 高精度倒计时用
performance.now()计算已过去时间，而非靠多次setTimeout累加 - 服务端或 Node.js 中需精准调度，考虑
setImmediate、process.nextTick（微任务）或专用库（如node-schedule） - 避免在定时器回调中执行重绘、大量 DOM 操作或同步计算，防止进一步拖慢后续任务
理解定时器的本质是“调度请求”而非“执行指令”，就能更合理地设计异步逻辑，减少因执行时机偏差引发的 bug。
