闭包本身不泄漏，问题在于它意外延长了本该短命对象的生命周期；在大型spa中，闭包常作为“中转站”将组件实例、dom节点、大型缓存等挂到全局或长生命周期对象上，导致路由跳转后仍驻留内存。

闭包本身不泄漏，问题在于它意外延长了本该短命对象的生命周期。在大型 SPA 中，闭包常作为“中转站”，把组件实例、DOM 节点、大型缓存等关键对象，悄悄挂到全局或长生命周期对象上，导致路由跳转后仍驻留内存。

看堆快照里带 “bound” 和箭头函数的监听器

Chrome DevTools 堆快照的 Closure 区域是突破口。重点关注函数名含 bound 或匿名箭头函数（如 function () { ... }）的条目——它们大概率捕获了外层作用域变量。展开其 Scope，检查是否持有 this、vm、props、state 或直接引用了 document.getElementById 返回的 DOM 节点。

• 典型信号：一个 keydown 监听器闭包里显示 this.closeModal，而该组件早已卸载
• 对比操作前后快照，过滤 HTMLDivElement 或 Array 类型，看哪些实例的 Retained Size 持续增长却未释放

查“retained by”链中不该存活的中间节点

内存无法回收，往往卡在某一层中间引用上。比如链路是：window → eventListeners → bound handler → closure → component → data → large cache。不能只盯着最后的 large cache，要逐层确认：

• eventListeners 下的监听器是否本应在组件卸载时清除，却因没保存函数引用而漏解绑
• bound handler 是否由 _.throttle(fn, 300) 生成，且 throttle 实例被模块级变量长期持有
• 第三方库（如地图 SDK、图表库）注册的回调是否返回了清理句柄，但你没调用

盯住定时器与异步回调里的 this / state 引用

setInterval 或 Promise.then 中若直接访问组件响应式数据或方法，极易形成隐性强引用：

• 错误写法：setInterval(() => this.updateStatus(), 5000) —— 即使组件已销毁，timer 仍在运行并持有着 this
• 修复要点：把 timer ID 存为 ref；清理函数中先 clearInterval，再确保异步回调内做 if (!mounted) return 判断
• 注意 Axios 请求 + then 链：若请求返回时组件已卸载，then 回调里的 setState 会触发警告并保留对旧 state 的引用

验第三方库的“自动清理”是否真生效

很多库文档写着“自动销毁”，实际依赖使用者显式调用：

• echarts 实例必须手动调用 dispose()，否则 canvas 和事件监听全滞留
• video.js 播放器需执行 player.dispose()，否则内部 buffer 和网络连接持续占用内存
• lodash.throttle/debounce 默认不提供清理接口，若传入的函数是闭包，整个闭包链就锁死了外部变量