setInterval最危险的是任务堆积而非不准，因其“按时发车”不等前次执行完；推荐用setTimeout递归替代，辅以执行锁与时间校准，并在组件卸载时清除定时器防内存泄漏。

setInterval 最危险的地方，不是它不准，而是它“不管不顾”——前一次回调还没执行完，后一次已经塞进任务队列了。一旦执行时间超过设定间隔，任务就开始堆积，主线程被拖垮，Vue 响应式更新反复触发，页面卡顿甚至假死。

任务堆积的底层原因

setInterval 的设计逻辑是“按时发车”，不看前一趟是否到站。浏览器只负责在指定时间点把回调推入任务队列，不管主线程此刻是否空闲、上一个回调是否还在运行。

• 设定了 100ms 间隔，但回调实际耗时 150ms → 第二个回调准时排队，第一个刚结束它就立刻执行
• 连续多个回调积压后，事件循环持续处理定时任务，UI 渲染、用户交互被严重挤压
• 在 Vue 中，每次回调若触发 data 更新，就会激活依赖收集和 patch 流程，进一步放大性能损耗

用 setTimeout 递归替代（推荐首选）

让下一次执行严格等在上一次完成之后，从根源切断堆积链路。

• 写法简洁：不要直接调用 setInterval，改用 setTimeout 自调用
• 示例：

  this.timer = null;
  const tick = () => {
    this.fetchData();
    this.timer = setTimeout(tick, 1000);
  };
  this.timer = setTimeout(tick, 1000);

• 优势：天然防堆积、可动态调整延迟（比如根据接口响应时间重算下次 delay）

加执行锁 + 时间校准（适合轮询场景）

当必须控制“最小间隔”且允许略慢、但绝不能重叠时，用状态标记 + 时间判断更稳妥。

• 定义标志位：this.isFetching = false
• 每次进入回调先检查：if (this.isFetching) return;
• 执行前设为 true，结束后设为 false，并用 performance.now() 记录起始时间，确保两次真实间隔 ≥ 设定值
• 适用于轮询接口类需求，能避免请求雪崩和重复提交

组件卸载时务必清除定时器

这不是锦上添花，是防止内存泄漏的底线操作。

• Vue 2 在 beforeDestroy，Vue 3 在 onBeforeUnmount 中调用 clearTimeout 或 clearInterval
• 建议统一管理：把所有定时器 ID 存进数组，销毁时遍历清除
• 漏掉这一步，组件实例被闭包持有，数据、DOM 节点全无法回收