闭包本身不是问题，关键在于控制其对外部变量的引用强度和生命周期；需及时清理事件监听与定时器、避免长期持有大对象、减少闭包数量、用WeakMap缓存、借助Memory面板定位泄漏。
闭包本身不是问题，问题在于它让本该被回收的变量“活”得太久。关键不是消灭闭包，而是控制它对外部变量的引用强度和生命周期。
及时清理事件监听和定时器
这是最常见的泄漏源头。闭包作为事件回调或定时器函数时，若未主动移除，就会持续持有对外部作用域的引用。
- 绑定事件后，务必在不需要时调用 removeEventListener，且传入与添加时完全相同的函数引用（不能是匿名函数）
- 使用 setTimeout 或 setInterval 后，记得保存返回的 ID，并在合适时机调用 clearTimeout 或 clearInterval
- 在单页应用中，组件卸载、页面切换前应统一执行清理逻辑，比如返回一个 cleanup 函数
避免闭包长期持有大对象
当闭包引用了大型数组、DOM 元素或深层嵌套对象时，哪怕只保留一个引用，整个结构都难以被回收。
- 提取必要字段而非直接引用整个对象，例如把
el换成el.id或el.dataset.key - 不再需要时，显式将闭包内引用的大变量设为 null，切断强引用链
- 对必须缓存的对象，考虑用 WeakMap 存储——它的键是弱引用，对象被销毁后，对应条目自动失效
控制闭包创建的范围和数量
循环中为每个元素创建独立闭包，极易累积大量无法释放的引用。
- 优先采用 事件委托，用父容器统一代理子元素事件，只需一个闭包
- 若必须逐个绑定，循环结束后手动清空引用，比如将
element.onclick = null - 用 IIFE 或模块封装隔离作用域，防止变量意外泄露到全局或上层作用域
借助工具定位真实泄漏点
凭经验猜测容易误判。浏览器开发者工具的 Memory 面板能直观反映内存增长趋势和对象保留路径。
- 录制操作前后两次堆快照，对比新增的、未释放的闭包实例及其引用链
- 配合代码打日志或使用 console.trace() 辅助判断闭包何时创建、是否被重复绑定
