Chrome DevTools Memory面板是定位JavaScript内存泄漏的第一道防线，支持Heap snapshot、Allocation instrumentation on timeline和Record heap allocations三种方式，其中Heap snapshot对比最常用。
Chrome DevTools 的 Memory 面板能直接定位内存泄漏
内存泄漏在 JavaScript 中往往表现为页面长时间运行后变卡、崩溃，或 heap size 持续上涨。Chrome DevTools 的 Memory 面板是第一道防线，它支持三种核心检测方式：Heap snapshot、Allocation instrumentation on timeline、Record heap allocations。
实际操作中优先用 Heap snapshot 对比：先空闲状态下拍一张快照，执行可疑操作（如打开关闭模态框 10 次），再拍第二张，用 Comparison 视图筛选 Retained Size 大且数量持续增长的对象。重点关注 Closure、Detached DOM tree、Array 和自定义类实例。
- 避免只看
#Objects总数——有些对象小但数量爆炸（如事件监听器闭包），真正危险的是Retained Size累积 - 若发现大量
Detached HTMLDivElement，说明 DOM 节点被 JS 引用但未从文档移除，常见于缓存了element.parentNode.removeChild(element)后仍保留对element的引用 -
Allocation instrumentation适合追踪“谁在持续分配”，但开销大，仅用于短时间复现路径
WeakMap 和 WeakRef 是主动防御内存泄漏的实用工具
传统用 Map 或普通对象做缓存时，key 是强引用，容易阻止 GC 回收；而 WeakMap 的 key 必须是对象，且不阻止其被回收——这天然适配「为 DOM 节点附加元数据」这类场景。
const nodeMetadata = new WeakMap();
function attachTooltip(element, text) {
// element 是弱引用 key，即使页面移除了 element，nodeMetadata 不会阻止它回收
nodeMetadata.set(element, { tooltipText: text, shown: false });
}
// 后续 element 被 removeChild 或 innerHTML = '' 后，对应 entry 自动消失
WeakRef（ES2025）更进一步，允许你持有对象的弱引用并手动检查是否还存活：
- 适用于需要延迟清理、但又不能阻塞目标对象释放的场景（如资源池、缓存代理）
- 注意
WeakRef.deref()可能返回undefined，必须判空 - 不要用
WeakRef包裹基本类型（数字、字符串）——它只接受对象
Lighthouse 无法检测运行时内存泄漏，但它能暴露高风险模式
Lighthouse 的 Performance 审计项本身不抓堆快照，但它的 Reduce JavaScript execution time 和 Avoid large layout shifts 等报告，常指向隐含内存问题的代码结构。例如：
- 审计提示 “Long tasks > 50ms” 频繁出现，可能因监听器里做了大量同步计算 + 缓存未节流，导致对象堆积
- “Avoid enormous network payloads” 同时伴随内存占用飙升，说明你可能把整段 JSON
JSON.parse()后长期持有，而非按需提取字段 - 它不会告诉你
addEventListener没配{ once: true }，但如果你在组件卸载后仍有定时器或事件监听器活跃，Lighthouse 的 “Minimize main-thread work” 分数会明显下降
Node.js 环境下用 --inspect + Chrome 内存工具分析服务端泄漏
浏览器前端只是半场，Node.js 服务长期运行同样会内存泄漏，比如 Express 中中间件反复 app.use() 注册未清理的闭包，或数据库连接池配置不当。
启动时加 --inspect 参数，然后在 Chrome 地址栏打开 chrome://inspect → 连接你的 Node 进程，就能用和前端完全一致的 Memory 面
板操作。
- 关键区别：Node 中要关注
NativeObject和C++ ArrayBuffer占比，它们可能来自 fs.readFile、crypto 或 native addon - 用
process.memoryUsage()打点日志比截图更有效——监控heapUsed是否随请求线性增长 - 避免在生产环境长期开启
--inspect，调试完记得关掉，否则有安全与性能风险
真正的难点不在工具怎么点，而在判断「这个对象该不该被回收」——比如一个全局 Map 存着用户 session 数据，它看起来像泄漏，其实是设计如此；而另一个本该随组件销毁的 ResizeObserver 实例却挂在 window 上，这才是真泄漏。工具只报现象，归因靠你对业务生命周期的理解。
