定时器未清除导致内存泄漏，核心原因是回调函数持续存活并形成闭包，长期持有外部变量、DOM节点等引用，使垃圾回收器无法释放；如React组件卸载后未清理setInterval，this和props仍被引用，造成Detached DOM和内存持续增长。
定时器未清除导致内存泄漏，核心原因是：回调函数持续存活，连带它所引用的所有外部变量、对象、DOM 节点等，都无法被垃圾回收器释放。
回调函数长期驻留，锁住整个引用链
setInterval 每次触发后不会自动销毁，只要没调用 clearInterval，它的回调就始终在内存中“挂起”。而这个回调是个闭包，天然捕获定义时作用域里的变量——比如组件实例、大型数组、DOM 元素、响应式状态等。只要回调还在，这些被引用的对象就一直是“可达的”，GC 就不敢动它们。
例如：
- 一个 React 组件里启动了 setInterval，回调里用了 this.state 或 props.data；组件卸载后，如果没清理定时器，this 和 props 依然被回调持有，整棵组件树无法回收
- 回调里直接操作 document.getElementById('chart')，即使该元素后来被 remove()，只要 JS 还拿着引用，它就变成“Detached DOM”，占内存不释放
页面卸载后定时器仍在后台运行
用户关闭标签页或跳转路由时，若定时器未显式清除，浏览器仍会维持其任务队列中的回调待执行项。尤其当回调内有 fetch、console、DOM 更新等操作时，不仅浪费 CPU，还会不断拉取新数据、创建新对象，进一步加剧内存增长。
实际表现是：打开开发者工具 → Memory 面板 → 多次拍快照对比，能看到 Closure 类别持续膨胀，Retained Size 明显上升；任务管理器里该标签页内存占用只升不降，最终卡顿甚至崩溃。
闭包 + 全局/长期对象 = 隐形强引用
更隐蔽的情况是，定时器回调本身被赋值给了全局变量、类属性、模块级缓存，或作为事件监听器绑定在长期存在的对象上。这时即使原组件已销毁，回调仍通过这些“锚点”牢牢挂在内存里，连带捕获的上下文一起固化。
典型例子：
- 把 setInterval 回调赋给 window.timerHandler（全局污染）
- Vue 实例中 this.timerId = setInterval(...)，但 beforeUnmount 里忘了 clearInterval(this.timerId)
- React useEffect 中启动定时器，却没返回清理函数
现代方案更可靠：用 AbortController 配合 setTimeout
对于需要取消的一次性延时任务，优先使用支持 signal 的 setTimeout（需配合 AbortController）：
const controller = new AbortController();
setTimeout(() => { console.log('done'); }, 5000, { signal: controller.signal });
// 页面离开前调用
controller.abort();
虽然 setInterval 尚未原生支持 signal，但可通过封装 + 标志位 + 清理函数组合实现类似效果，关键是确保销毁路径明确、可执行。
