闭包本身不导致内存泄漏，但长期持有大对象引用会引发问题；常见场景包括未解绑事件监听器、未清除定时器、全局持有闭包及不当捕获大对象。
闭包本身不等于内存泄漏，但一旦它长期持有对大对象的引用，而这些对象本该被回收，问题就出现了。关键不是“用了闭包”，而是“闭包被谁拿着、又抓了什么”。
事件监听器未解绑
这是前端最常见的一类泄漏：用闭包函数做事件处理，绑定后组件却卸载了，监听器没清除，闭包连带整个父作用域（含 DOM 节点、数据、配置等）一起卡在内存里。
- 单页应用中反复创建/销毁组件时尤其危险
- 异步操作完成后再绑定监听器，容易遗漏解绑逻辑
- 推荐做法：组件销毁前统一调用 removeEventListener；或使用支持自动清理的封装（如 React 的 useEffect 清理函数、Vue 的 beforeUnmount）
定时器未清除
setInterval 或 setTimeout 的回调是闭包，如果它访问了组件实例、DOM 元素或大型数据，而定时器没在页面离开或组件卸载时清除，这些对象就一直被“钉”在内存中。
- 典型表现：切换路由后控制台还在打印日志，或性能面板显示内存持续增长
- 务必在合适时机调用 clearInterval/clearTimeout，并确保变量可访问（避免闭包捕获已失效的 this 或局部变量）
- 可考虑用 WeakMap 存储 timerId，关联到目标对象，便于统一销毁
全局或长生命周期对象持有闭包
把闭包赋给 window、模块导出对象、class 实例属性或缓存结构，等于给它发了一张“永久居留证”。只要这个宿主还活着，闭包和它捕获的所有变量都动不了。
- 比如缓存函数时直接用普通对象存储：cache[key] = () => doSomething(largeData)
- 解决思路：限制缓存大小、设置过期时间；优先用 WeakMap（键为对象时，对象被回收后对应缓存自动失效）
- 避免将闭包挂到全局，改用显式生命周期管理（如 create + destroy 配对）
闭包捕获了不该捕获的大对象
一个本该轻量的闭包，因为写法不当，悄悄“背走”了整个数据列表、DOM 树甚至整个组件实例。
- 循环中用 var 声明变量再传入闭包 → 所有闭包共享同一变量，结果错乱且延长生命周期
- 创建多个闭包共用同一词法环境 → 即使只用其中一个函数，所有被捕获的数据（config、cache、largeData）全得留着
- 优化建议：按需拆分闭包；用参数传值替代捕获；对大对象手动置 null 或提前解除引用
