内存泄漏是对象本该不可达却因意外引用保持可达，导致gc无法释放；常见诱因包括隐式全局变量、未清理事件监听器、定时器长期持引用、闭包不当保留大对象及dom引用残留。
内存泄漏不是垃圾回收（GC）失灵，而是对象本该“不可达”却因意外引用一直保持“可达”，导致 GC 无法释放——理解这点，就抓住了问题核心。
常见诱因：哪些操作让对象“假活”
GC 的标记-清除机制只回收不可达对象。以下情况会让本该被回收的对象持续被引用：
-
隐式全局变量：函数内未声明就赋值（如
a = []），变量自动挂到window上，整个生命周期都存活；this在非严格模式下指向全局对象，也可能意外挂载数据。 -
未清理的事件监听器：DOM 元素已移除，但
addEventListener绑定的回调仍存在，回调闭包又引用着外部大对象或该 DOM 节点本身，形成强引用链。 -
定时器长期持有引用：用
setInterval或setTimeout启动的回调中访问了外部变量（如大型数组、组件实例），而定时器未在组件卸载时清除，变量就一直无法释放。 -
闭包不当保留大对象：返回的内部函数显式使用了外部作用域中的大体积数据（如
new Array(1e6)），只要该函数还被持有（如赋值给全局变量或缓存），外部数据就无法被 GC 回收。 -
DOM 引用残留：JS 中用
let el = document.getElementById('x')保存节点引用后，即使该节点已被removeChild或innerHTML替换，只要el变量未置空，这个 DOM 节点就仍是“可达”的，变成 Detached DOM Tree。
Chrome DevTools 实战排查四步法
不用猜，靠数据对比定位真实泄漏点：
- 录制内存变化曲线：打开 Performance 面板 → 勾选 Memory → 点击录制 → 执行多次相同操作（如打开/关闭弹窗）→ 停止。观察内存图表是否阶梯式上升，而非周期性回落。
-
拍三张堆快照比对：切换到 Memory 面板 → Heap Snapshot → 先拍一张基准快照（Snapshot 1）→ 执行疑似泄漏操作一次 → 拍第二张（Snapshot 2）→ 再执行两轮 → 拍第三张（Snapshot 3）。将 Snapshot 3 切换为 Comparison 视图，与 Snapshot 1 对比，重点关注
Delta列持续增长的类型（如Closure、HTMLDivElement、自定义类名）。 -
搜 Detached 节点：在任意快照的搜索框输入
Detached，查看是否有大量脱离 DOM 但仍被 JS 引用的元素；点击展开可看到具体是哪个变量（如window.cache.el）在持有着它。 - 看分配时间线找源头：用 Allocation Timeline 模式录制操作，暂停后按 Constructor 排序，找到高频分配且长期不释放的对象构造器，再结合调用栈定位代码位置。
修复关键：切断不该存在的引用链
修复不是“等 GC”，而是主动让对象变不可达：
- 启用
"use strict"，杜绝隐式全局变量；所有变量用let或const明确声明。 - 事件监听器必须配对移除：
addEventListener后，在组件销毁或元素移除前调用removeEventListener，注意函数引用要一致（避免用匿名函数）。 - 定时器统一管理：用
let timerId = setInterval(...)，在不需要时明确调用clearInterval(timerId)并将timerId设为null。 - DOM 引用及时清空：不再需要的节点引用，手动设为
null（如el = null）；缓存 DOM 的对象结构，也要在清理阶段遍历置空。 - 大对象闭包用完即断：若闭包必须返回，使用完毕后主动将闭包函数引用设为
null；更稳妥的做法是避免在闭包中直接捕获大对象，改用 ID 或轻量标识间接访问。
不复杂但容易忽略——泄漏往往藏在“看起来没问题”的引用里，关键是养成“谁创建、谁清理”的习惯，并用工具验证直觉。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
