闭包导致内存泄漏最常见，因其常用、隐蔽且易无意绑定大对象或DOM节点；它通过作用域链延长变量生命周期，使本应释放的对象因可达性而无法被垃圾回收。
闭包在内存泄漏场景中最常见，不是因为它本身危险，而是它太常用、太隐蔽、又太容易“无意中绑住不该绑的东西”。它不像全局变量那样一眼可见，也不像未清除定时器那样有明显痕迹，而是在你写事件处理、封装逻辑、做缓存时自然出现，稍不注意就悄悄拖住大对象或 DOM 节点。
闭包天然具备“延长变量生命周期”的能力
JavaScript 的垃圾回收靠的是可达性判断：只要一个对象还能被某个活跃的执行上下文访问到，就不能回收。闭包正是通过作用域链维持这种可达性——哪怕外层函数早已执行完毕，只要闭包还被持有（比如作为事件监听器、定时器回调、模块导出函数），它捕获的所有变量（包括大型数组、组件实例、DOM 元素）都会一起“赖着不走”。
- 一个本该只用一次的按钮点击处理函数，若用箭头函数写成
() => console.log(this.data)，就捕获了整个组件实例 - 循环中用
var声明索引再绑定事件，所有闭包共享同一个i，不仅逻辑错乱，还让整个循环作用域无法释放 - 缓存函数里直接闭包捕获原始数据，而不是传 ID 或快照，导致数据一直被钉在内存里
闭包常与长期存活对象“深度绑定”
它很少单独存在，总是依附在更难销毁的对象上：全局对象、DOM 节点、定时器、第三方观察器……这些对象本身生命周期长，一旦把闭包挂上去，就等于给闭包发了张长期居留证。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
window.addEventListener('resize', () => this.update())—— 每次都新建闭包，卸载组件时却没清理，window 就一直拽着组件和它的全部状态 -
setInterval(() => el.innerHTML = data, 100)—— el 被移除后，只要定时器还在跑，节点就无法回收，形成 Detached DOM tree -
const observer = new ResizeObserver(cb)，但忘了调用observer.disconnect()，内部闭包持续持有回调和它引用的一切
开发习惯放大了闭包泄漏风险
现代框架鼓励函数式写法、Hook 式逻辑、高阶组件封装，这些都大量依赖闭包。而开发者往往更关注功能实现，忽略引用管理：
立即学习“Java免费学习笔记（深入）”；
- React 中 useEffect 里创建的闭包，依赖项没写全，清理函数拿不到最新
this或 ref，导致解绑失效 - Vue 中在
mounted绑定事件，却在beforeUnmount忘记移除，尤其用了 lodash.throttle 等工具函数时，容易漏掉.cancel() - 用普通对象做缓存：
cache[key] = () => heavyTask(data)，data 无法释放，cache 又没过期机制
泄漏不易被察觉，直到性能明显下降
小闭包泄漏几 KB，用户无感；但单页应用反复进入/退出页面，每个组件都留下几个闭包+DOM+数据，几十次后就可能累积上百 MB。Chrome Memory 面板里看到的 Detached DOM tree、不断增长的 JS heap、retainers 显示 Closure → Component → largeArray，往往就是闭包在“背锅”。
- 切换路由后控制台还在打印日志？说明定时器或监听器没清干净
- 滚动几次后内存不回落？大概率是 scroll 事件监听器闭包捕获了渲染容器或数据列表
- 组件卸载后 state 还能被访问？说明闭包里的 this 或 ref 没被切断
