闭包本身不泄漏内存，真正泄漏的是被其意外长期持有的对象；需用devtools内存快照定位retainers，排查全局挂载、未解绑事件、未清理定时器、缓存滥用四类高危模式，并通过轻量捕获、事件委托、及时清理和weakmap等手段优化。
闭包本身不泄漏内存，但一旦它捕获了不该长期持有的变量，又没被及时释放，就会让这些变量“卡”在内存里——真正泄漏的是那些被闭包意外拴住的对象。
先定位：用 DevTools 找出谁在“拽着”闭包
别靠猜，直接看内存快照：
- 打开 Chrome DevTools → Memory 面板 → 点击 ● 拍第一张堆快照（操作前）
- 执行疑似泄漏的操作（比如反复打开/关闭一个模块、滚动列表多次）
- 再拍一张快照 → 切换到 Comparison 视图 → 筛选 Constructor 为 Closure 或你项目中具体的函数名
- 点开增长明显的闭包项 → 右侧看 Retainers 树：重点找 window、EventListener、setInterval、Map.entries 这类长期存活的持有者
查常见泄漏模式：四类高危写法
以下结构出现时，要立刻检查是否切断了引用：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
全局挂载闭包：把回调函数赋给
window.handler = () => {...}，而里面用了大数组或 DOM 节点 -
事件监听器未解绑：用闭包函数绑定
addEventListener，但组件卸载或元素移除后没调用removeEventListener -
定时器没清理：在闭包里访问
this或局部大对象，却忘了clearInterval或clearTimeout - 缓存滥用闭包保存引用：用闭包维护一个 Map 缓存结果，但没设 TTL、没淘汰机制、也没用 WeakMap
优化关键：让闭包“轻量”且“可控”
不是不用闭包，而是控制它捕获什么、活多久：
- 只提取真正需要的字段：
const { id, name } = item;，再让闭包捕获这两个值，而不是整个item对象 - 异步传参优先用 setTimeout 第三参数：
setTimeout((id) => console.log(id), 100, item.id)，避免闭包捕获整个作用域 - 列表渲染避开逐个闭包：用事件委托 +
data-id查找，而不是为每个<button onclick="{()"> handleClick(item)}></button> - 手动切断引用链：组件卸载前，把闭包变量设为
null；监听器统一注册、统一清理；定时器封装成带.clear()方法的对象
预防性习惯：从编码开始减少风险
有些做法看似小，但能拦住大部分泄漏：
- 所有模块加
'use strict'，杜绝意外全局变量 - DOM 引用尽量不缓存，非要缓存就用
WeakMap，以 DOM 元素为键 - 大型状态对象不直接闭包，改用计算后传参：
onClick={() => handleClick(item.id)} - 用 ESLint 开启
no-unused-vars和no-undef，配合 TypeScript 提前暴露冗余引用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
