Chrome DevTools Memory面板需先手动GC再拍堆快照，对比多时间点快照关注(closure)等增长对象，排查addEventListener未解绑、全局缓存、定时器未清除等泄漏模式，WeakMap/WeakRef需配合主动断强引用，并通过显式destroy方法和performance.memory验证清理效果。
Chrome DevTools 的 Memory 面板怎么用
直接打开 chrome://inspect → 选中目标页面 → 点击 “Open dedicated DevTools for Node”（如果是网页就点 “Open in Elements” 后切到 Memory 面板）——关键不是点开，而是别跳过「录制前先 GC」这步。
常见错误：点了 “Take heap snapshot” 就以为完事了，结果 snapshot 里堆着大量没被回收的闭包、事件监听器、定时器。必须先手动点 Collect garbage（小垃圾箱图标），再拍快照，否则数据失真。
实操建议：
- 对比多个时间点的快照：比如操作前、操作后、再次操作后，用
Comparison视图筛选Objects allocated between snapshots - 重点关注
(closure)、HTMLDivElement、EventListener这类条目持续增长 - 右键某构造函数 →
Reveal in Summary view，看它关联的 retaining path（谁在强引用它）
哪些代码模式最容易引发泄漏
不是所有闭包都危险，但以下几种结构在真实项目中高频出问题：
立即学习“Java免费学习笔记（深入）”；
常见错误现象：页面反复进入/退出某个模块，内存占用阶梯式上涨，刷新也不降。
典型泄漏模式：
-
addEventListener绑定后没配对调用removeEventListener，尤其在单页应用组件销毁时遗漏 - 全局变量缓存 DOM 节点或大数组，比如
window.cache = []或document.body.myData = {...} - 使用
setTimeout/setInterval且回调内持有外部作用域变量，定时器未clear就卸载组件 - 第三方库（如旧版
lodash.throttle）返回的防抖函数被长期持有，内部闭包锁住原始上下文
WeakMap 和 WeakRef 真的能“自动”防泄漏吗
不能。它们只是提供弱引用能力，不等于泄漏免疫——你得主动把强引用断掉，WeakMap 才有机会让值被回收。
使用场景有限制：WeakMap 的 key 必须是 object，不能是 string/number；WeakRef 的 deref() 返回可能为 undefined，必须做空值检查。
性能与兼容性影响：
-
WeakMap在 Chrome/Firefox/Edge 16+ 支持良好，但 Safari 15.4 之前有WeakMap内存不释放的 bug -
WeakRef是较新特性（ES2021），Node.js 14.6+、Chrome 84+ 可用，但 SSR 环境或老浏览器需降级处理 - 别为了“显得高级”而滥用：一个简单
Map加手动delete，往往比嵌套WeakRef+FinalizationRegistry更可靠
如何写可测的内存清理逻辑
核心原则：清理动作必须显式、可触发、可验证。别依赖 “组件 unmount 时框架会帮你清”。
实操建议：
- 组件类里统一暴露
destroy()方法，在beforeUnmount（Vue）或componentWillUnmount（React class）中调用 - 每个
addEventListener都用同一个handler函数（别用箭头函数），确保removeEventListener能匹配上 - 用
performance.memory做简易监控（仅 Chromium）：console.log(performance.memory.usedJSHeapSize)，观察操作前后差值 - 自动化难，但可以写个最小复现页：只保留疑似泄漏的模块 + 强制 GC 按钮，方便快速验证修复是否生效
最常被忽略的一点：泄漏往往不出现在你写的业务代码里，而在你 import 的工具函数或封装的 hook 里——那些没文档说明“需要手动 cleanup”的第三方小包，才是真正的内存黑洞源头。
