闭包本身不泄漏，问题在于它意外延长了本该短命对象的生命周期；在大型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 默认不提供清理接口，若传入的函数是闭包，整个闭包链就锁死了外部变量
