闭包本身不会导致内存泄漏，问题在于它长期持有对大对象的强引用且未及时释放；常见场景包括未解绑的事件监听器、未清除的定时器、循环中创建的冗余闭包，以及将闭包挂载到全局或长生命周期对象上。
闭包本身不是问题，问题在于它“不该留却一直留着”的引用关系。当闭包长期持有对大对象（比如大型数组、DOM 元素、组件实例）的强引用，而这些对象本该被释放时，内存就卡住了。
事件监听器绑定后没解绑
这是最常见也最容易忽视的泄漏点：用箭头函数或匿名函数作为事件回调绑定到 DOM 元素，但元素被移除或组件卸载后，监听器没清除，闭包连带捕获的整个作用域（含 data、this、DOM 节点等）全部滞留内存。
- 典型写法：
btn.addEventListener('click', () => console.log(userData)) - 风险在于：SPA 中组件反复挂载/卸载，监听器越积越多
- 排查信号：Memory 面板中看到 detached DOM 节点仍被 Closure 引用
定时器回调未清理
setInterval 或 setTimeout 的回调是闭包，若它访问了组件状态、DOM 元素或大型数据，而定时器没在页面离开或组件销毁时清除，这些对象就一直被“钉”住。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 典型反例：
setInterval(() => updateChart(this.data), 2000)—— 组件已卸载，this.data还在跑 - 更隐蔽的是 timer ID 存在模块级变量里，但忘记调用
clearInterval - 修复关键：确保清理逻辑能执行，且变量在闭包外可访问
循环中为每个项创建冗余闭包
在 for / forEach 中为多个元素分别绑定处理函数，每个都形成独立闭包，且常意外捕获整个循环上下文或大对象。
立即学习“Java免费学习笔记（深入）”；
- 比如：
items.forEach((item, i) => el[i].onclick = () => console.log(item, bigList)) - 100 个元素 → 100 个闭包 → 100 份对
bigList的引用 - 优化方向：改用事件委托；或只捕获必要字段，避免闭包“背走”整块数据
闭包被挂到全局或长生命周期对象上
把闭包赋值给 window、模块顶层变量、class 实例属性或缓存 Map，等于给它发了张“永久居留证”。只要宿主活着，闭包和它捕获的一切都动不了。
- 例如：
window.cacheFn = () => doSomething(largeData) - 或手动缓存：
cache.set(key, () => heavyCompute(data))——data永不释放 - 推荐替代：WeakMap（以对象为 key）、带 TTL 的缓存、或显式
destroy接口
