定时器未清除是 JavaScript 中最隐蔽的内存泄漏源头之一，需显式保存 ID、在组件卸载时主动清理、避免回调强引用、结合 visibilitychange 暂停轮询，并通过堆快照与定时器工厂函数监控兜底。
定时器未清除是 JavaScript 中最隐蔽也最常被忽视的内存泄漏源头之一。它不报错、不阻断逻辑，却让回调函数持续持有外部作用域引用，使本该释放的对象一直驻留在内存中——尤其在单页应用（SPA）里，组件反复挂载/卸载时，漏掉一次清理，就可能累积数 MB 甚至上百 MB 的残留。
明确保存并统一管理定时器 ID
不能靠“记得清除”，而要让清除这件事可追踪、可验证：
- 每次创建
setInterval或setTimeout时，必须用const或let显式声明并保存其返回值（ID） - 避免在闭包或箭头函数内部直接调用定时器却不暴露 ID；更不要把 ID 存在全局或难以定位的对象里
- 在 React 中，推荐封装成自定义 Hook，把 ID 存在 ref 中，确保跨渲染周期可访问
在生命周期结束时主动触发清理
定时器的生命周期必须与业务逻辑对齐，而不是依赖“页面关闭”这种不可控时机：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在 Vue 中，务必在
beforeUnmount（或unmounted）钩子中调用clearInterval/clearTimeout - 在 React 函数组件中，必须在
useEffect的清理函数中清除，且依赖数组要合理设置（例如空数组 [] 表示仅在挂载后清理） - 若定时器用于轮询数据，且用户切换 Tab 或离开当前模块，应结合 visibilitychange 事件或路由守卫提前暂停，而非等组件卸载才清理
避免回调函数形成隐式强引用链
即使清除了定时器 ID，若回调本身捕获了大型对象（如整个组件实例、大数组、DOM 节点），GC 仍无法回收这些对象：
立即学习“Java免费学习笔记（深入）”；
- 不要在定时器回调里直接使用
this、props或state等易变引用；优先提取所需字段，或用useCallback+ 依赖数组控制捕获范围 - 若回调需访问组件状态，用
ref.current替代闭包捕获，避免因状态更新导致旧回调持续持有所有历史 state 副本 - 对高频定时器（如每 100ms 执行），考虑节流或改用
requestAnimationFrame，减少 GC 压力和引用堆积
加一层防御性检查与监控
人工清理总有疏漏，需要用机制兜底：
- 开发环境可加简单检测：在定时器回调开头打日志或计数，配合 Chrome DevTools 的 Performance 面板观察是否重复触发
- 上线前用 Memory 面板录制堆快照（Heap Snapshot），筛选
setInterval相关的闭包，查看其 retained size 和引用路径 - 关键业务模块可封装定时器工厂函数，自动记录创建位置、超时时间、是否已清理，并支持全局 debug 模式输出未清理列表
