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 节点全无法回收
