未清理的定时器是JavaScript内存泄漏最常见原因：组件卸载后定时器仍运行，通过闭包强引用state、DOM等对象，阻碍垃圾回收；须在生命周期结束时显式clearInterval/clearTimeout并避免过度捕获。
未清理的定时器（setInterval 或 setTimeout）是 JavaScript 内存泄漏最常见、也最容易被忽视的原因之一。它不报错，但会让组件卸载后仍“偷偷运行”，持续持有闭包捕获的 state、ref、DOM 节点甚至大型数据，导致这些对象无法被垃圾回收。
看控制台是否还在“自言自语”
这是最快速、最直观的判断方式：
- 切换路由、关闭弹窗、切走浏览器 Tab 后，如果控制台仍在打印日志（如
console.log('tick')）、发起请求或更新状态，说明定时器没停 - 尤其注意轮询类逻辑（如订单状态刷新、倒计时、心跳检测），它们常在
useEffect或mounted中启动，却忘了配对清理 - React 中常见误写：
useEffect(() => { setInterval(...); }, [])—— 缺少返回的清除函数，定时器会一直跑下去
用 Chrome Memory 面板抓“滞留的闭包链”
打开 DevTools → Memory 面板 → 拍摄堆快照（Heap Snapshot），重点观察以下线索：
- 筛选
(closure)，找占用内存大、数量异常增长的闭包项 - 点开它的 Retainers 标签页：若路径出现
Timer → Callback → Closure → DOM element，说明定时器正强引用已移除的节点 - 若路径含
Window → global variable → Timer → Closure → large array，说明闭包把本该随组件销毁释放的数据锁死了 - 对比操作前后的快照，在 Comparison 视图中关注
Detached DOM tree和Closure类别是否明显增加
查代码里定时器是否“有始无终”
不是所有 setInterval 都危险，关键是看它是否与生命周期脱钩：
立即学习“Java免费学习笔记（深入）”；
-
useEffect 清理缺失：写了启动，没写
return () => clearInterval(id) -
条件启停不匹配：只在
if (loading)里启动，却没在else或finally中清理 - keep-alive 场景误判：组件没销毁但视图已隐藏（如 Tab 切换），轮询应暂停而非继续执行
-
定时器 ID 被覆盖：多次调用
setInterval，但清理时只清了最后一次的 ID，前面的仍在后台运行
验证回调是否意外拖住大对象
定时器本身小，真正吃内存的是它闭包里“顺手带上”的东西：
- 是否直接访问了整个
props、this.state或ref.current，而不是仅需的字段？ - 是否引用了未浅拷贝的大数组、图表配置、缓存数据等？
- 是否通过
document.getElementById获取后长期持有 DOM 节点？ - 是否绑定了 WebSocket、Canvas 上下文、音视频元素等重型资源？
只要这些对象被闭包捕获，而定时器没停，它们就一直驻留在内存里。
