有效使用Chrome DevTools Memory面板需对比快照：空闲时拍一张，执行疑似泄漏操作后再拍一张，用Comparison视图筛选“Objects allocated between snapshots”，重点关注Detached DOM tree、重复增长的Closure/Array、意外全局变量。
Chrome DevTools 的 Memory 面板怎么用才有效
直接打开 Memory 面板点“Take heap snapshot”拍快照，往往看不出问题。关键在对比：先空闲状态下拍一张，再执行疑似泄漏的操作（比如打开又关闭一个模态框），再拍一张，最后用 Comparison 视图筛选 Objects allocated between snapshots。
重点关注三类对象：
-
Detached DOM tree：已从文档移除但 JS 仍持有引用的节点（常见于事件监听器未清理、缓存了innerHTML字符串却保留了旧节点引用） - 重复增长的
Closure或Array实例（尤其带长字符串或大对象） - 意外持有了全局变量（如
window.xxx = {...}或未声明的变量赋值）
闭包和事件监听器为什么总导致泄漏
闭包本身不等于泄漏，但当它捕获了大型外部对象（比如整个 document、DOM 节点或大数组），且该闭包被长期持有的回调（如定时器、未移除的 addEventListener）引用时，就锁住了整条引用链。
典型陷阱：
立即学习“Java免费学习笔记（深入）”；
-
element.addEventListener('click', handler)后没调用element.removeEventListener('click', handler) - 用
setTimeout或setInterval传入匿名函数，且 timer ID 未保存或未清除 - React 中在
useEffect里添加监听器，但 cleanup 函数里漏写了removeEventListener - 第三方库（如图表库）初始化后没调用
.destroy()方法
WeakMap 和 WeakRef 真的能防泄漏吗
它们只能缓解特定场景，不是万能解药。
WeakMap 适合做「私有数据存储」：键必须是对象，且不阻止垃圾回收——只要该对象没其他强引用，即使它还在 WeakMap 里也会被回收。但如果你把 DOM 节点当 key 存进去，又在别处用变量强引用了这个节点，那依然泄漏。
WeakRef 更底层，需手动调用 .deref()，返回可能为 undefined；它不自动触发清理逻辑，得配合 FinalizationRegistry 才能做资源释放，但注册的回调**不保证及时执行**，不能依赖它做关键清理（比如关 WebSocket、释放 canvas 上下文）。
Node.js 环境下怎么查前端代码的内存泄漏
前端代码跑在 Node 里（比如 SSR、Jest 测试、Puppeteer 脚本）时，不能靠 Chrome 面板。要用 process.memoryUsage() 监控 RSS 和 heapUsed 变化，再结合 node --inspect 启动，用 Chrome 的 chrome://inspect 连上去拍堆快照。
更实用的是写检测脚本：
- 用
global.gc()（需启动时加--expose-gc）强制 GC 后对比内存差值 - Jest 测试中，在
afterEach里检查globalThis上意外挂载的属性 - Puppeteer 中，用
page.evaluate(() => performance.memory?.usedJSHeapSize)抓页面内 JS 堆大小（仅 Chromium 支持）
真正难定位的，往往是跨上下文引用：比如 Service Worker 缓存了页面对象，或 Web Worker 持有主线程传来的结构化克隆后的副本——这些在快照里显示为孤立节点，但根源在通信协议设计上。
