判断闭包内存泄漏的核心是看其是否被长期持有并拖住不该留存的对象；需用devtools拍堆快照对比closure数量与retained size，检查捕获变量、运行时异常及代码中定时器、事件监听和全局挂载三类高危结构。
判断代码中是否存在闭包引起的内存泄漏，核心是看“闭包是否被长期持有，且拖住了不该留下的对象”。不是所有闭包都有问题，关键在于它有没有在任务结束后继续存活，并把大型数据、DOM 节点或组件实例等强引用牢牢锁住。
用 DevTools 拍快照对比 Closure 变化
打开 Chrome 开发者工具 → Memory 面板 → 点击 “Take heap snapshot” 拍摄初始快照。执行疑似泄漏的操作（比如反复打开关闭弹窗、切换 Tab），再拍一张。切换到 Comparison 视图，筛选类型为 Closure，重点关注：
- 数量持续增长的闭包（尤其函数名重复出现）
- 单个闭包的 Retained Size 明显偏大（如超几百 KB）
- Retainers 列中显示 Timer、EventListener、window 或已移除的 DOM 元素
检查闭包实际捕获了哪些变量
在快照中点开某个 Closure 实例，展开其 Closure context 或 Scope，确认它绑定了什么。高危信号包括：
- 整个 DOM 节点（而你只用了它的
id或textContent） - 大型数组、JSON 数据、未释放的 Canvas 上下文
- 本该随组件卸载而销毁的 state、store 实例、WebSocket 连接
- 只用
obj.name却捕获了整个obj—— 这类冗余引用可优化
观察运行时异常行为
有些泄漏会在页面行为上露出马脚，不需要工具也能初步怀疑：
- 组件卸载后，控制台仍在打印日志（比如定时器没停、轮询还在跑）
- 反复操作同一功能模块，内存占用阶梯式上升，GC 后不回落
- 移除了 DOM 元素，但事件监听器仍生效（右键元素 → “Break on” → “attribute modifications” 可验证）
- 全局缓存（如 Map、window 属性）中对象数量持续增长，且 key 是 DOM 或组件实例
代码层面快速筛查重点
翻代码时，盯紧这三类高危结构：
-
定时器回调：用了
setInterval或setTimeout，但没配对调用clearInterval/clearTimeout -
事件监听绑定：用箭头函数或匿名函数绑定
addEventListener，却没在合适时机（如组件卸载）调用removeEventListener -
意外挂载到长生命周期对象上：把闭包赋值给了
window.xxx、模块级Map、单例类属性，或路由守卫、WebSocket 实例等不易销毁的对象
