闭包本身不会导致内存泄漏，问题在于被长期持有并捕获大对象。常见场景包括未解绑事件监听器、未清除定时器、全局对象持有闭包、以及闭包捕获不必要的大对象。
闭包本身不会导致内存泄漏，问题出在它被长期持有，同时又捕获了本该释放的大对象——比如 DOM 节点、大型数组、组件实例等。只要闭包还“可达”，它所引用的变量就无法被垃圾回收器清理。
事件监听器没解绑
这是最普遍的泄漏源头。用闭包函数做点击、滚动等回调，绑定后组件却卸载了，但 removeEventListener 没调用，闭包连带它捕获的整个作用域（DOM 节点、state、大型数组）全卡在内存里。
- 单页应用反复切换页面时，容易累积多个未清理的监听器
- 异步加载后动态绑定监听器，常漏掉清理逻辑
- 推荐统一管理：React 用 useEffect 清理函数，Vue 用 beforeUnmount，原生 JS 可维护 listeners 数组批量清除
定时器没清除
setInterval 或 setTimeout 的回调是闭包，只要它还在跑，里面访问过的 this、DOM 元素、bigData 就一个都收不走。
- 典型表现：路由跳走后控制台还在打印日志，或内存面板显示持续增长
- 务必在组件销毁、页面离开前调用 clearInterval/clearTimeout
- 避免闭包直接引用大对象；必要时只传 ID 或轻量字段，而不是整个数据结构
全局或长生命周期对象持有闭包
把闭包赋给 window、模块导出对象、class 实例属性，等于给它发了张“永久居留证”。宿主不死，闭包和它捕获的所有变量就动不了。
- 比如缓存函数写成 cache[key] = () => doSomething(largeData)，largeData 就一直被锁住
- 优先用 WeakMap（键为对象时，对象回收后缓存自动失效）
- 必须用全局缓存时，加 TTL 过期机制，或手动置 null 清理
闭包捕获了不该捕获的大对象
一个轻量回调，因为写法松散，偷偷背走了整棵树。比如循环中用 var 声明变量再传入闭包，所有闭包共享同一变量，不仅逻辑错乱，还延长了整个作用域生命周期。
- 多个闭包共用一个外层作用域时，哪怕只用其中一个函数，所有被捕获的数据（config、cache、largeArray）全得留着
- 优化方向：按需拆分闭包；用参数传值替代捕获；对大对象手动切断引用（如设为 null）
- 排序、搜索等算法中，避免在闭包内直接引用百万级数组，改用索引或 ID 间接操作
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
