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，彻底替代前端定时拉取