闭包导致内存泄漏的根源在于长期持有无需变量，需及时清除定时器/事件监听器、避免全局引用、精简dom/大对象引用、减少循环闭包、警惕隐式强引用并主动置null。
闭包本身不是问题，问题在于它悄悄“抓着”不该留的变量不放。只要切断那些不再需要的引用，垃圾回收器就能顺利清理，内存泄漏自然消失。
及时清理定时器和事件监听器
闭包常被用在 setInterval、setTimeout 或事件回调里，一旦绑定却忘记清除，闭包就会一直持有外部变量，让它们无法释放。
- 每次创建定时器，都要配套提供清除逻辑，并在合适时机调用（比如组件卸载、页面离开前）
- 给 DOM 元素绑定事件时，优先使用 removeEventListener 解绑，而不是靠元素被移除来间接释放
- 避免把闭包直接赋值给全局或长生命周期对象（如 window、class 实例属性），否则引用链难以中断
谨慎处理大对象和 DOM 引用
如果闭包里用了图片、Canvas、大型数组，或者直接引用了某个 DOM 节点，这些资源体积大、回收成本高，一旦被闭包长期持有可能迅速拖慢页面。
- 在闭包内部只保留真正需要的数据，比如用 ID 或字符串代替整个 DOM 元素
- 对大对象做浅拷贝或提取必要字段，避免无意中延长整个对象树的生命周期
- 组件销毁时，主动将闭包内相关引用设为 null，明确告诉引擎“这个不用了”
减少循环中闭包的滥用
for 循环里为每个元素生成独立闭包，容易造成大量相似但无法复用的函数实例，尤其当循环次数多、外部变量大时，风险明显上升。
- 优先用事件委托替代逐个绑定，把多个闭包压缩成一个
- 必须循环绑定时，把 handler 提前定义好，避免在循环体内反复声明函数
- 配合 cleanup 数组统一管理解绑动作，确保每一条引用都有出口
警惕隐式强引用场景
有些引用不是写出来的，而是语言机制自带的——比如匿名函数自动捕获外层 this、arguments，或者箭头函数悄悄绑定了上下文。
- 在类方法中使用箭头函数作回调时，注意它会牢牢抓住实例，导致整个实例无法回收
- 避免在闭包中直接引用整个 class 实例，改用传参方式传递所需字段
- 调试时可用 Chrome DevTools 的 Memory 面板拍快照，比对前后差异，定位“滞留对象”
