JavaScript中setInterval的“累积延迟”本质是主线程阻塞导致回调实际执行时间持续后移，而系统级计时器仍按计划触发；Event Loop在宏任务执行完后才检查定时器并入队，若主线程长期占用，多次到期回调会在同一空闲窗口批量执行，形成堆积感。
JavaScript 中 setInterval 的“累积延迟”不是定时器本身变慢了，而是任务队列阻塞导致回调**实际执行时间不断向后推移**，而定时器内部的计时器（如系统级 timer）仍在按计划触发——只是触发后进不了事件循环的执行阶段。分析这个问题，关键在理解 Event Loop 如何调度宏任务、检查定时器状态，以及主线程是否被长期占用。
定时器触发 ≠ 回调立即执行
setInterval(fn, 100) 每 100ms 会向宏任务队列添加一个任务（前提是前一次回调已出队并执行完毕）。但如果某次 fn 执行耗时 200ms，那么：
- 第 1 次回调在 t=100ms 进入队列，t=100ms 开始执行，t=300ms 结束
- 第 2 次触发（t=200ms）时，主线程仍在执行中 → 该任务被丢弃或排队等待（取决于浏览器实现，但不会叠加执行）
- 第 3 次触发（t=300ms）时，主线程刚空闲 → 该任务立刻入队，紧接着被执行
- 结果：看起来像是“延迟了 200ms”，且后续所有回调都卡在“上一轮结束时刻”之后紧挨着执行，形成“堆积感”
Event Loop 调度过程决定是否累积
每次 Event Loop 迭代包含：执行一个宏任务 → 清空微任务队列 → 检查定时器（是否到期）→ 渲染 → 下一轮。注意：
- 定时器检查发生在宏任务执行完、微任务清空后，不实时；即使系统时钟已过期，也要等当前宏任务结束才能把回调加入队列
- 如果宏任务（比如长循环、复杂计算、同步 I/O 模拟）持续运行 > 定时间隔，那么多次到期的
setInterval回调会在下一次检查时“集中发现”，但只会入队一个（多数浏览器去重），其余被忽略 - 真正造成“累积感”的是：多个间隔本该分散执行，却因主线程忙，被迫挤在同一个空闲窗口里顺序执行（看似连发）
如何验证和定位延迟来源
用带时间戳的日志 + 长任务模拟，观察实际执行间隔：
立即学习“Java免费学习笔记（深入）”；
let start = performance.now();
setInterval(() => {
const now = performance.now();
console.log(`计划: ${(start + (Date.now() - start) % 1000) | 0}ms, 实际: ${now.toFixed(1)}ms, 偏差: ${(now - start).toFixed(1)}ms`);
start += 100; // 理想基准递增
}, 100);
<p>// 主线程压测（阻塞 400ms）
setTimeout(() => {
const t = Date.now();
while (Date.now() - t < 400) {} // 同步忙等
}, 500);
你会看到：在阻塞结束后，连续打出 3–4 条日志，每条“偏差”值相差约 100ms，但“实际”时间几乎相同 —— 说明它们是在同一轮 Event Loop 的宏任务阶段被批量取出并执行的。
避免累积延迟的实用策略
不用依赖 setInterval 的“准时”，改用更可控的链式调度：
-
用
setTimeout递归代替：每次回调结束再设下一次，确保前一次彻底完成才启动倒计时 - 记录上次执行时间，动态调整下次延迟：补偿已发生的延迟，让长期平均间隔趋近目标值
- 将耗时逻辑拆分或移交 Web Worker：避免主线程长时间阻塞，保障定时器检查及时性
-
对非关键定时任务，启用
requestIdleCallback或节流（throttle）处理，主动让出主线程
本质上，这不是 bug，而是单线程 + 事件驱动模型的自然表现。理解 Event Loop 的每个环节何时检查定时器、何时入队、何时执行，就能预判并规避“看似准时、实则漂移”的陷阱。
