setInterval不会真正累积，所谓“累积”是因回调耗时超间隔导致排队执行；应改用递归setTimeout确保每次执行完再触发下一次，从而避免扎堆、卡顿和状态错乱。
setInterval 本身不会“累积”，所谓“累积效应”其实是由于定时器回调执行时间超过设定间隔，导致多次回调排队执行，看起来像任务堆积。要避免这种现象，核心思路是确保每次执行完成后再安排下一次，而不是固定间隔重复触发——这就引出了用递归 setTimeout 替代 setInterval 的做法。
为什么 setInterval 容易出现“假累积”
当 setInterval 设置为每 100ms 执行一次，但某次回调耗时 150ms，那么下一次回调不会被取消，而是等前一次结束后立刻执行（甚至可能连续触发两次）。浏览器会尽力按周期插入任务，但不保证执行时机精准，也不跳过延迟的任务。结果就是回调“扎堆”，视觉或逻辑上表现为卡顿、重复操作、状态错乱。
用递归 setTimeout 确保串行可控
递归 setTimeout 的本质是：每次回调执行完，才用 setTimeout 启动下一轮。它把“下一次执行”变成一个主动决策，而非被动调度。
- 写法简单：在回调末尾调用 setTimeout，传入自身函数和延时值
- 天然防堆积：只要上一次没结束，下一次就不会启动
- 便于动态控制：可在任意时刻清除（只需清除当前 pending 的 timeout）
示例：
立即学习“Java免费学习笔记（深入）”；
let timerId = null;function tick() {
// 执行实际逻辑（比如更新UI、发请求）
console.log('tick');
// 完成后才安排下次
timerId = setTimeout(tick, 100);
}
// 启动
timerId = setTimeout(tick, 100);
// 清除
clearTimeout(timerId);
更健壮的封装：带启动/停止控制的定时器类
直接手写递归容易遗漏清理或状态管理。可封装一个轻量类，明确生命周期：
- 内部只持有一个 active 标志和当前 timeout id
- start 方法检查是否已运行，避免重复启动
- stop 方法清除 pending timeout 并重置状态
- 支持传入自定义 delay 和 this 上下文（用 bind 或箭头函数）
这样既避免了 setInterval 的调度不可控，又比裸写 setTimeout 更易维护和复用。
什么情况下仍可用 setInterval
并非所有场景都要替换。如果回调是纯计算、极快（微秒级），且逻辑允许轻微偏差（如轮询状态、动画帧同步），setInterval 简洁可靠。关键看是否依赖“严格串行”或“执行完成即刻再出发”。真正需要精确节拍（如音频同步、游戏逻辑）时，应结合 performance.now() 做时间校准，而非单纯依赖定时器间隔。
