KeepAlive 缓存下定时器必须在 deactivated 钩子中 clearInterval 并置空引用，同时在 activated 中重启；还需在 beforeDestroy/unmounted 中兜底清理，避免内存泄漏和功耗激增。
KeepAlive 缓存机制下，定时器若未及时清理，会在组件退到后台（deactivated）后继续执行，造成 CPU 占用、内存泄漏甚至电池快速耗尽——尤其在移动端或长时间驻留的管理后台中尤为明显。关键不是“能不能关”，而是“在哪个时机、用什么方式可靠地关”。
必须监听 deactivated 钩子清定时器
keep-alive 组件不会触发 beforeDestroy 或 unmounted，它只是被缓存而非销毁。因此仅靠 mounted + beforeDestroy 的老套路会完全失效。
- 在 deactivated 中调用
clearInterval(this.timer)并置空引用（this.timer = null） - 务必配合 activated 重启：组件重新激活时再 startTimer，避免残留状态
- 若 timer 是多个（如多个 setInterval 或 setTimeout），需统一管理（例如用数组存 id，遍历清除）
兼容销毁场景：beforeDestroy 仍要保留
keep-alive 的 max 属性或动态 include/exclude 可能导致组件被强制移出缓存并真正销毁。此时 deactivated 不会触发，必须兜底。
- 在 beforeDestroy（Vue 2）或 unmounted（Vue 3 Composition API）中再次执行清理逻辑
- 推荐将清理函数抽成独立方法（如
clearAllTimers()），两个钩子里都调用，避免遗漏 - 注意：Vue 3 的
onBeforeUnmount对应的是 unmounted 前一刻，和 beforeDestroy 语义一致
避免重复设定时器的坑
组件反复激活/失活时，如果 activated 里直接 setInterval 而不先清理，会导致多个定时器叠加运行——1秒打一次日志，变成 2 个、5 个、10 个……功耗指数级上升。
- 每次 startTimer 前，先执行
clearTimer()（哪怕 timer 已为 null，clearInterval 也安全） - data 中初始化
timer: null，便于判断和重置 - 复杂场景可加标记位（如
isTimerRunning: false），但非必需；优先靠清理+重设逻辑保障健壮性
进阶建议：用 requestIdleCallback 或 Visibility API 辅助降频
对非强实时任务（如轮询状态、上报埋点），可进一步降低后台功耗：
- 监听
document.visibilityState，页面隐藏时暂停定时器，显示时恢复 - 用
requestIdleCallback替代高频 setInterval，让浏览器在空闲时段执行，减少抢占 - 轮询类任务可结合后端长连接或 WebSocket，彻底替代前端定时拉取
