闭包泄漏源于意外持有大对象且被全局变量长期引用。通过Chrome堆快照按Retained Size筛选(closure)，追溯Retainers至window/global，结合多次操作对比Delta确认阶梯式增长，修复需禁用隐式全局、清理显式引用并解耦闭包依赖。
闭包本身不是问题，问题在于它意外持有了本该被释放的大对象，又因为全局变量或长生命周期引用让这些闭包无法被回收。Chrome DevTools 的堆快照分析器能直接暴露这类“隐性驻留”，关键在于看清楚谁在引用、谁没被释放。
定位可疑闭包：从 Retained Size 和构造函数入手
打开 Memory 面板 → Take heap snapshot → 在快照中切换到 Summary 视图，按 Retained Size 降序排列。重点关注以下几类：
- (closure) 类型的对象：这是 V8 标记的闭包实例，Retained Size 很大时，说明它背后绑定了大量数据
-
Object 或自定义构造函数（如
ChartRenderer、DataProcessor）下数量持续增长的实例 - 带有 global 或 window 引用路径的对象——点开其 Retainers 列，向上追溯，若发现引用链最终通向
window或global，基本可判定是全局变量积压
追踪引用链：确认闭包是否被全局变量“钉住”
选中一个高 Retained Size 的 (closure) 对象 → 右侧展开 Retainers 标签 → 逐层点击向上查看引用关系。常见泄漏路径包括：
-
window.myCache = function() { ... }→ 闭包通过全局属性被长期持有 -
var handler = function() { console.log(largeData); };（未声明变量）→ 自动挂到window.handler上 - 模块顶层作用域中定义的函数/对象被其他模块 import 后又未清理 → 实际形成跨模块全局引用
如果某闭包的 Retainer 最终指向 window.xxx 或 global.xxx，且该属性在业务逻辑中本不该长期存在（比如只用于一次初始化），就属于典型的闭包+全局变量双重泄漏。
对比快照验证：观察闭包实例是否“只增不减”
执行一组相同操作（如打开/关闭弹窗、切换 Tab）多次，每次操作后拍一张快照（Snapshot 1 → Snapshot 2 → Snapshot 3）：
- 切换到 Comparison 视图，选择 Snapshot 2 与 Snapshot 1 对比
- 筛选 (closure)，查看 Delta 列：若数量为 +10、+15、+20 持续递增，说明每次操作都在创建新闭包但旧的没释放
- 再对比 Snapshot 3 与 Snapshot 2，确认增长趋势是否稳定——阶梯式上升是闭包积压的强信号
修复要点：切断全局引用 + 主动释放闭包持有
找到泄漏源后，修复不单是删掉变量，而是打破引用链：
- 禁用隐式全局：在文件顶部加
'use strict';，避免漏写let/const导致变量自动挂 window - 清理显式全局：组件卸载、页面跳转前，手动置空全局缓存对象，如
window.chartInstances = null; - 解绑闭包依赖：若闭包内引用了大数组或 DOM 节点，改用局部变量或 WeakMap 存储；必要时在外部显式调用
fn = null;断开引用 - 避免在定时器/事件监听器中直接捕获大对象：改用 ID 或轻量标识代替，数据由外部按需查取
