JavaScript内存泄漏需通过理解机制、识别模式、动手验证、持续监控闭环解决；核心是掌握“为什么发生→在哪发生→怎么确认并修复”三层认知，结合V8标记-清除原理与五大高频场景排查。
先搞懂内存回收的真实逻辑
JS 没有手动 free()，但也不等于“写了就自动清”。V8 使用标记-清除（Mark-and-Sweep）为主，从全局对象（window、globalThis）、当前执行栈、定时器队列等“GC Roots”出发，追踪所有可达对象。只要一个对象能被某条引用链连到根上，它就不会被回收——哪怕你主观认为“这个数据早该扔了”。
关键点：
- 设
obj = null只有在它是唯一强引用时才有效；如果 DOM 节点还被事件监听器闭包持有着，设 null 没用 - 闭包不是泄漏元凶，但闭包意外保留大对象或 DOM 引用才是
- 现代浏览器已解决循环引用问题，不用再为
a.ref = b; b.ref = a担心
高频泄漏场景要像查错别字一样熟悉
以下五类代码，在真实项目中占内存泄漏问题的 90% 以上，建议对照自己项目逐行扫描：
-
未清理的事件监听器：组件卸载、页面跳转前没调
removeEventListener，尤其监听在window、document或全局 EventBus 上 -
遗忘的定时器：用
setInterval轮询数据，但组件销毁后没clearInterval，回调里又引用着 Vue 实例、React state 或大数组 -
意外的全局变量：漏写
let/const（如data = fetchData()），或非严格模式下this.xxx指向window -
DOM 引用残留：缓存了
document.getElementById('xxx')结果，之后 DOM 被移除，但 JS 变量仍持有引用 -
URL.createObjectURL 未释放：生成 blob URL 后没配对调用
URL.revokeObjectURL(url)，尤其在图片预览、文件下载场景
用 Chrome DevTools 真实抓一次泄漏
光看文档不如亲手拍三张堆快照。操作流程极简，但每步都不能跳：
- 打开目标页面 →
F12→ 切到 Memory 面板 - 点左上角 Collect garbage（小垃圾箱图标），清掉干扰项
- 点 Take heap snapshot，记为 “Snapshot 1”
- 执行疑似泄漏的操作（比如进组件、点按钮、滚动列表）
- 再次 Collect garbage → 再拍一张，记为 “Snapshot 2”
- 在 Snapshot 2 的右上角选 Comparison 视图，筛选 Objects allocated between Snapshot 1 and Snapshot 2
- 重点关注增长明显的：
(closure)、HTMLDivElement、EventListener、Array（尤其是长度异常大的）
看到某个 (closure) 持续增长？右键它 → Reveal in Summary view → 查看右侧 retaining path：谁在强引用它？往往一眼就能定位到是哪个未清除的监听器或定时器。
编码习惯比工具更重要
预防胜于排查。日常写代码时守住这几条线，能挡住绝大多数泄漏：
- 监听器注册后，明确配套清理逻辑；Vue 用
onBeforeUnmount，React 用useEffect返回函数，Node.js 用process.on('exit', ...)或自定义cleanup() - 所有
setTimeout/setInterval都赋值给变量，并在退出路径中清除 - 全局缓存加“有效期”和“手动清理入口”，比如
cache.set(key, value, { expires: Date.now() + 60e3 }) - 大对象只传必要字段，避免闭包锁住整个响应式对象或数据库结果集
- 用
WeakMap存储 DOM 元素私有状态（key 是 element，value 是配置），但注意：WeakMap 不解决你忘了删监听器的问题
不需要追求“绝对零泄漏”，重点是让内存使用呈周期性波动（操作→上升→GC→回落），而不是阶梯式爬升。只要观察到稳定平台期，就说明系统已进入健康状态。
