JS内存泄漏四大高发场景是未清除定时器、闭包意外持大对象、事件监听器未解绑、意外全局变量；Chrome DevTools通过堆快照对比、保留链分析和内存曲线录制三步定位；预防需配对清理定时器、显式解除闭包引用、使用once或正确解绑事件、启用严格模式。
掌握 JS 内存泄漏的常见陷阱与调试技巧，关键不在死记算法，而在于建立“引用可见”的直觉——知道谁在 hold 住对象，以及如何切断它。
四大高发泄漏场景，必须盯紧
这些不是理论假设，而是生产环境里反复出现的“内存钉子”：
- 未清除的定时器：setInterval 回调只要还在任务队列里，就持续持有外部变量。哪怕组件已卸载、页面已跳转，它仍在后台运行并阻止 GC。
- 闭包意外持大对象：一个返回函数的工厂函数，若内部创建了大型数组或缓存 Map，又没在使用后主动解除闭包引用（如设为 null），该数据会常驻堆中，永不释放。
- 事件监听器未解绑：给 DOM 元素绑定事件后，若元素被 remove() 或替换，但没调用 removeEventListener，回调函数及其闭包引用的数据仍被 EventTarget 持有。
- 意外的全局变量：忘记用 let/const/var 声明变量，直接赋值，它就会挂到 window（浏览器）或 global（Node.js）上，生命周期等同于整个页面或进程。
Chrome DevTools 实战三步定位法
不靠猜，靠证据：
- Memory 面板 → 拍摄堆快照（Heap Snapshot）：在疑似泄漏前后各拍一次，用“Comparison”模式对比，重点关注“Retained Size”突增的对象类型（比如 Array、Object、Closure）。
- 查看保留链（Retainers）：点击可疑对象，展开“Retainers”栏，顺着引用路径往上查——是哪个定时器？哪个未解绑的 listener？还是某个闭包函数？找到最上层“不该存在”的引用点。
- Performance 面板录制 + 内存曲线：勾选 Memory 复选框，录制用户操作流程（如打开/关闭弹窗多次），观察 heapUsed 是否阶梯式上升，确认是否稳定增长而非偶发抖动。
代码层面的预防性写法
把防御写进习惯，比事后修复更高效：
- 所有定时器都配对清理：React useEffect 返回清理函数，Vue onUnmounted 调用 clearInterval/clearTimeout，手动管理时务必保存 ID 并显式清除。
- 闭包返回函数后，明确生命周期：如果该闭包只用一次，用完立即赋值为 null；若需长期持有，检查它引用的外部变量是否真的必要，能懒加载就别预分配大数组。
- 事件监听优先用 { once: true }；非一次性监听，确保在合适时机（如组件销毁、DOM 移除前）调用 removeEventListener，并传入完全相同的函数引用（避免匿名函数）。
- 加 'use strict' 全局启用严格模式，让未声明变量直接报错，从源头杜绝意外全局。
Node.js 场景补充要点
服务端泄漏更隐蔽，但逻辑一致：
- process.memoryUsage().heapUsed 是第一哨兵，但需结合 GC 日志（--trace-gc）看回收频率与效果。
- 第三方 SDK 是重灾区：WebSocket 心跳、日志上报、数据库连接池回调，都可能形成 this 引用链或闭包滞留 Buffer/JSON 数据。
- 慎用 global.gc()：仅限开发调试，生产环境默认禁用，且强制 GC 可能引发 STW（Stop-The-World）停顿，不能替代代码修复。
