setTimeout/setInterval的延迟仅为最小等待时长，非精确执行时间；真实执行取决于宏任务队列状态、主线程空闲与否及微任务执行完毕后调度。
JavaScript 事件循环中，定时器（setTimeout、setInterval）的“延迟时间”只是最小等待时长，不是精确执行时间。真实执行时刻取决于任务队列状态、主线程是否空闲、以及宏任务/微任务调度节奏。
定时器不是“到点就执行”，而是“到点可执行”
当你调用 setTimeout(fn, 10)，浏览器或 Node.js 会在至少 10ms 后把回调注册为一个宏任务，放入**宏任务队列（Task Queue）**。但它必须等当前执行栈清空、且上一个宏任务（包括其内部所有微任务）全部完成后，才可能被取出来执行。
这意味着：如果主线程正忙于一个耗时 100ms 的同步任务，即使你设了 setTimeout(..., 5)，回调也要等到那 100ms 过后才开始排队，实际执行可能在 105ms 甚至更晚。
关键影响因素有哪些？
以下几类情况会直接拉长定时器的真实延迟：
立即学习“Java免费学习笔记（深入）”；
-
长任务阻塞：比如
while(Date.now() - start 或大量 DOM 操作，会让事件循环无法及时轮转 -
高频率微任务挤压：连续触发
Promise.then、MutationObserver等，会持续清空微任务队列，推迟下一个宏任务的执行 -
嵌套定时器 + 任务堆积：例如在
setTimeout回调里又立即创建新定时器，而前一个还没执行完，就会形成“延迟滚雪球” -
浏览器节流策略：标签页非激活时，多数浏览器会将定时器最小间隔限制在 1000ms；后台 tab 中
setTimeout(fn, 10)可能延后数秒才执行
怎么测出真实延迟？
不要只看设定值，要用 performance.now() 记录精确时间戳对比：
const start = performance.now();
setTimeout(() => {
const delay = performance.now() - start;
console.log('设定 20ms，实际延迟：', delay.toFixed(2), 'ms');
}, 20);
进阶技巧：
- 用
performance.mark()+performance.measure()做多点标记，分析整段流程耗时 - 配合
console.time()观察某段逻辑是否意外拖慢了定时器响应 - 在 DevTools 的 Performance 面板 录制运行过程，查看 Event Log 中
Timer Fired事件与Function Call的时间差
如何让定时器更可控？
若对时机敏感（如动画、采样、心跳），避免依赖 setTimeout 的绝对精度：
- 用
requestAnimationFrame替代 16ms 定时器做视觉更新——它和屏幕刷新率同步，无排队风险 - 对周期性任务，改用“执行完立刻计划下一次”的方式：
function tick() { /* work */ setTimeout(tick, 50); }
这样能避免因单次延迟导致后续全盘偏移 - 必要时用
Web Worker把计算密集型逻辑移出主线程，释放事件循环压力
