JavaScript 中闭包导致内存泄漏的常见模式有哪些

闭包本身不会导致内存泄漏，问题在于它长期持有对大对象的强引用且未及时释放。常见场景包括：未解绑的事件监听器、未清除的定时器、循环中创建的冗余闭包、以及将闭包挂载到全局或长生命周期对象上。

闭包本身不会导致内存泄漏，问题出在它“不该留却一直留着”的引用关系上。当闭包长期持有对大对象（如 DOM 元素、大型数组、组件实例）的强引用，而这些对象本该被释放时，内存就卡住了。

事件监听器绑定后未解绑

这是最常见也最容易忽视的泄漏点：用箭头函数或匿名函数作为事件回调绑定到 DOM 元素，但元素被移除或组件卸载后，监听器没清除，闭包连带捕获的整个作用域（含 data、this、DOM 节点等）全部滞留内存。

• 典型写法：btn.addEventListener('click', () => console.log(userData));
• 风险在于：SPA 中组件反复挂载/卸载，监听器越积越多
• 排查信号：Memory 面板中看到 detached DOM 节点仍被 Closure 引用

定时器回调未清除

setInterval 或 setTimeout 的回调是闭包，若它访问了组件状态、DOM 元素或大型数据，而定时器没在页面离开或组件销毁时清除，这些对象就一直被“钉”住。

• 典型反例：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 接口

不复杂但容易忽略：闭包不是敌人，问题在于谁拿着它、它抓了什么。盯住“谁在持有闭包”和“闭包里有什么”，就能快速定位泄漏源头。