setInterval 会“穿插”是因为它只按固定时间发起任务，不等待前次完成；递归 setTimeout 则确保前次彻底结束才启动下一轮，避免并发与状态混乱。

用 setInterval 定时执行任务时，如果任务执行时间超过设定间隔，就会出现“执行穿插”——即上一次还没结束，下一次又触发了，导致并发、状态混乱甚至内存泄漏。根本解法不是调大间隔，而是改用递归 setTimeout，确保前一次任务彻底完成，才安排下一次。

为什么 setInterval 会“穿插”？

setInterval 只负责“按时发起”，不关心上次是否结束。比如设为 100ms，但某次任务耗时 150ms，那么第 2 次调用会在第 100ms 准时开始（此时第 1 次还在跑），第 3 次在第 200ms 开始……很快形成多个并行执行的实例。

常见于：轮询接口、动画帧控制、日志上报等实际耗时不可控的场景。

递归 setTimeout 的核心逻辑

每次任务执行完，再用 setTimeout 主动发起下一轮。这样“启动时机”由上一轮结束决定，天然规避重叠。

• 不是“固定间隔触发”，而是“完成之后再等 X ms”
• 任务体内部无需加锁或防重入，逻辑更干净
• 便于动态调整下次延迟（例如失败后退避重试）

写法示例与关键细节

基础结构：

<!-- 错误：setInterval -->
setInterval(() => apiCall(), 2000);

✅ 正确写法：

function poll() {
  apiCall().then(() => {
    setTimeout(poll, 2000); // 成功后才设下一次
  }).catch(() => {
    setTimeout(poll, 5000); // 失败延后重试
  });
}
poll(); // 启动

注意点：

• 避免在任务中直接调用自身（如 poll() 放在 then 外），否则会立即递归，栈溢出
• 需要手动清理时，只需清除当前 pending 的 timeout ID（用 clearTimeout）
• 若需精确间隔（如动画对齐 requestAnimationFrame），可记录起始时间，动态计算补偿延迟

何时仍可用 setInterval？

仅适用于任务是纯同步、确定快于间隔的场景，例如：

• 更新毫秒级倒计时显示（DOM 操作极轻量）
• 心跳信号（空请求，超时短且服务端有幂等）
• 开发调试时快速验证逻辑（非生产环境）

一旦涉及异步、网络、DOM 计算或用户交互响应，优先选递归 setTimeout。