精准判定闭包内存泄漏的关键是识别“本该释放却长期驻留且拖着大内存的闭包”，须严格按清场→操作→清理→再清场→对比→追链闭环执行，结合快照对比、Retained Size分析、[[Scopes]]展开及Retainers路径追踪定位根因。
精准判定闭包内存泄漏，核心不是看有多少个 (closure)，而是确认“本该释放却长期驻留、且拖着大内存的那几个”。整个过程必须闭环：清场 → 操作 → 清理 → 再清场 → 对比 → 追链。
拍对快照：先手动 GC，再抓关键节点
不清理就拍，快照里全是噪音。必须严格按顺序操作：
- 打开 Memory 面板，点左上角垃圾桶图标，强制触发一次垃圾回收
- 等页面完全空闲（无定时器、无动画、无 pending 请求）后，立即拍下第一张快照（Baseline）
- 执行目标操作（如打开/关闭弹窗、切换路由、刷新数据列表），然后**主动清理**：调用 dispose()、removeEventListener()、把引用变量设为 null、清空 Map/Set 缓存
- 再次点垃圾桶 → 立即拍第二张快照
对比筛选：盯住 (closure) 的 Delta 和 Retained Size
选中第二张快照 → 右上角切为 Comparison 模式 → 在 Constructor 列输入 (closure)（注意括号、小写，这是 V8 的固定标记）：
- 重点看 # New 列为红色 + 号、且数值持续增长的项（比如每次操作都新增 1–3 个）
- 更关键的是 Retained Size：单个
(closure)占几百 KB 甚至 MB 级，才构成实质泄漏风险 - 忽略 Function 构造函数下的普通函数——它们生命周期短；
(closure)才是真正捕获了外部作用域、被长期强持的对象
展开 [[Scopes]]：看清它到底锁住了什么
双击一个可疑的 (closure) → 右侧 Properties 中找 [[Scopes]] → 展开 Closure 类型的 scope：
- 这里列出的变量名（如
data、chartInstance、this.$el）就是它实际捕获的内容 - 如果只用
id却捕获了整个user对象，或只渲染 DOM 却持有整棵document.body，就是典型冗余捕获 - Shallow Size 很小（几十字节）但 Retained Size 巨大，说明问题不在闭包本身，而在它兜底的大对象
顺 Retainers 追到根因：终点决定修复方向
在同一个闭包对象上，切到右侧 Retainers 标签页 → 点 Retaining paths → 务必勾选 Show all objects（否则漏掉 GC 可达但未回收的对象）：
- 路径终点是
window.xxx或globalThis.cacheMap→ 检查是否误挂全局、缓存未清理 - 终点是
EventListener，且对应 DOM 显示为Detached HTMLDivElement→ 事件监听器未解绑，尤其注意 removeEventListener 是否用了相同引用 - 终点是
Timeout或Interval→ 定时器未清除，闭包随回调长期存活 - 终点是某个 class 实例（如
Uploader、ChartView）→ 实例未销毁，或其属性（如this.handler）仍持有着闭包
交叉验证：用 Allocation Timeline 锁定创建源头
若怀疑是“高频新建”而非“旧闭包不释放”，换轻量方式：
- 切到 Performance 面板 → ⋯ 菜单 → 勾选 Allocation instrumentation on timeline（注意不是 Memory 面板里的同名选项）
- 点 Record → 执行一次操作（如点击按钮 5 次）→ Stop
- 时间轴上找持续亮起的蓝色条带 → 点击蓝块 → 左侧堆栈直接定位到生成闭包的代码行（如某处
return () => { ... }） - 特别留意名字含
debounced、throttled、onResize、uploadHandler的闭包，它们最容易因未清理而堆积
