必须在组件卸载前清除定时器，否则会因闭包持有this导致内存泄漏和运行时错误；Vue 3 推荐用 ref 存储 timer ID，并在 beforeUnmount 中统一清理并置空。
因为定时器是独立于组件生命周期运行的异步任务，一旦启动，就会持续持有对组件实例（this）的强引用。组件卸载后，若不清除，JS 引擎无法回收该实例及其所有关联对象——包括响应式数据、$refs、store 状态、事件监听器等，最终造成内存泄漏和运行时错误。
定时器会阻止组件实例被垃圾回收
setInterval 或 setTimeout 的回调函数形成闭包，天然捕获当前作用域中的 this。即使组件已从 DOM 移除、unmounted 钩子执行完毕，只要定时器还在运行，这个闭包就一直存在，整个组件实例就被“钉”在内存里。
- heap snapshot 中可见
VueComponent实例数不降反升 - performance 录制显示 JS 堆内存阶梯式增长，GC 频繁触发但收效甚微
- chrome://inspect 可定位到闭包中残留的
this.$refs.xxx或store.state.xxx
未清除会导致运行时报错
定时器回调仍可能在组件销毁后触发，此时访问 ref.value、调用 emit、修改 reactive 数据，都会抛出类似 “Cannot read property ‘xxx’ of null” 或 “Updating a component after it has been unmounted” 的错误。
Vue Composition Analyzer
下载
分析 Vue 3 Composition API 使用情况——审计响应式模式、可组合函数设计、ref 与 reactive 的选择、计算属性、watcher 使用及组件……
- 典型场景：轮询接口返回后执行
this.loading = false，但组件已卸载 - 更隐蔽的问题：
computed或watch内部依赖了定时器更新的值，引发连锁响应异常
多个定时器或动态启停时风险更高
当组件支持开关轮询、响应 props 变化重启定时器，或封装了自定义 Hook，容易因逻辑疏漏留下多个未清理的 timer ID。
- 只清除了旧 timer，新 timer 已覆盖变量 → 旧定时器继续运行
- timer 存在局部变量里，被 effect 闭包捕获旧值 → 清理时传入的是过期 ID
- 未判断 timer 是否为 null 就直接
clearInterval→ 控制台报错干扰调试
Vue 3 推荐统一使用 beforeUnmount + ref 管理
这是目前最清晰、最不易出错的实践方式：用 ref 显式保存 timer ID，在 beforeUnmount 中安全清除并置空。
-
beforeUnmount是组件卸载前最后一个可执行同步逻辑的钩子，时机可靠 - 配合
ref管理 ID，避免闭包陷阱，支持多定时器、动态重设等复杂场景 - 清除后将 ref 设为
null，便于后续判断和调试
