JavaScript垃圾回收通过标记-清除自动释放不可达对象内存，但全局变量残留、未清除定时器、未解绑事件监听器、闭包过度持有及控制台日志等会导致内存泄漏。
JavaScript 的垃圾回收机制（Garbage Collection，GC）是引擎自动管理内存的过程：它会定期识别并释放那些**不再被程序访问的变量、对象所占用的内存**。开发者不用手动 free 内存，但若理解不到位，就容易造成内存泄漏——即本该被回收的对象一直留在内存中，导致内存占用持续升高、页面变卡甚至崩溃。
常见的垃圾回收算法：标记-清除
现代 JavaScript 引擎（如 V8）主要用“标记-清除”（Mark-and-Sweep）方式：
- 从一组根对象（如全局变量、当前执行函数的局部变量、DOM 元素引用等）出发，递归标记所有能被访问到的对象；
- 未被标记的对象被视为“不可达”，随后被清除并回收内存。
注意：引用计数（Reference Counting）曾被部分老引擎使用，但它无法处理循环引用问题（比如两个对象互相引用），V8 等主流引擎已不依赖它。
典型内存泄漏场景及原因
以下情况会让对象意外保持“可达”，逃过垃圾回收：
立即学习“Java免费学习笔记（深入）”；
-
全局变量残留：无意中给全局对象（
window或globalThis）挂载了大对象或回调函数，比如window.cacheData = hugeArray，后续忘了清理； -
定时器未清除：用
setInterval或setTimeout时，回调函数里闭包引用了外部大对象，且定时器没被clearInterval清除，该回调和它捕获的变量就一直存活； -
事件监听器未解绑：给 DOM 元素添加了事件监听器（如
btn.addEventListener('click', handler)），但元素被移除后没调用removeEventListener，handler 及其闭包中的数据仍被持有； - 闭包过度持有：内部函数长期存在（如暴露给全局或存入缓存），又引用了外层作用域的大对象（如整个 DOM 节点、大型数组），外层变量无法释放；
-
控制台日志保留引用：在 Chrome DevTools 中用
console.log(obj)打印一个大对象后，即使代码里已无引用，控制台仍可能隐式持有它（尤其展开查看过），影响 GC 判断（仅开发环境需注意）。
如何检测和验证内存泄漏
借助浏览器开发者工具的 Memory 面板：
- 录制堆快照（Heap Snapshot）：操作前拍一张，操作后（如打开关闭模块多次）再拍一张，对比“#Objects”和“Shallow Size”变化；
- 查看“Retainers”：选中疑似泄漏的对象，看谁在引用它（比如某个闭包、事件监听器、全局变量）；
- 使用 Allocation Instrumentation on Timeline：记录内存分配过程，观察是否有持续增长且不下降的构造函数（如反复创建未销毁的类实例）。
简单验证法：强制触发 GC（DevTools → Memory → Collect garbage 按钮），再看内存是否回落。若多次操作后内存只升不降，大概率存在泄漏。
基本上就这些。垃圾回收本身很可靠，问题往往出在我们“以为对象已失效”，其实还被某处悄悄引用着。写代码时多问一句：“这个对象什么时候该被释放？谁还在拿着它？” 就能避开大多数坑。
