JavaScript垃圾回收采用标记-清除算法：先从根对象递归标记可达对象，再清除未标记的不可达对象；常见泄漏原因包括意外全局变量、未清理事件监听器、未清除定时器、闭包过度捕获和DOM引用残留。
JavaScript 的垃圾回收（GC）机制是引擎自动管理内存的核心能力，它不依赖开发者手动释放，而是通过识别“不可达对象”并回收其占用内存来维持运行时健康。当前所有主流引擎（如 V8、SpiderMonkey）都采用 标记-清除（Mark-and-Sweep） 作为基础算法，而非早期已被淘汰的引用计数——后者无法处理循环引用，极易引发内存泄漏。
标记-清除是怎么工作的？
整个过程分两步：
-
标记阶段：从根对象（如全局对象
window或global、当前执行栈中的变量、活跃 DOM 节点等）出发，递归追踪所有能被访问到的对象，并打上“活跃”标记； - 清除阶段：扫描整个堆内存，回收所有未被标记的对象——这些就是真正“不可达”的垃圾。
这个机制天然能处理循环引用问题。比如两个对象互相引用但外部已无任何引用，它们在标记阶段不会被触及，最终会被一并清除。
哪些操作容易导致内存泄漏？
虽然 GC 自动运行，但若代码中存在隐式强引用，就会让本该被回收的对象“卡住”。常见高发场景包括：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
-
意外的全局变量：忘记用
let/const声明变量，导致它挂载到window（浏览器）或global（Node.js）上，长期驻留； -
未清理的事件监听器：DOM 元素被移除后，若仍通过
addEventListener绑定着监听函数，且该函数闭包内持有对该元素的引用，元素就无法被回收； -
定时器未清除：
setInterval或setTimeout的回调函数若引用了外部大对象，而定时器未被clearInterval/clearTimeout清理，该对象将一直存活； - 闭包过度捕获：内部函数无意中保留了对外部大型数组、缓存对象甚至整个 DOM 树的引用，且该函数生命周期很长（如作为事件处理器长期存在）；
- DOM 引用残留：JS 中保存了对已从文档中移除的节点的引用（例如缓存在变量或 Map 中），节点及其子树都无法释放。
怎么有效防范内存泄漏？
关键不是“阻止 GC”，而是“减少不必要的强引用”。实用建议如下：
- 始终启用
"use strict"，避免隐式全局变量； - 在组件卸载、页面跳转或模块销毁前，显式调用
removeEventListener和clearInterval/clearTimeout； - 对需长期存在的回调，考虑使用
WeakMap或WeakSet存储关联数据——它们不阻止键/值被回收； - 闭包中只引用真正需要的最小数据，用完后可主动设为
null（尤其针对大型对象或 DOM 节点）； - 借助 Chrome DevTools 的 Memory 面板做 Heap Snapshot 对比，定位持续增长的对象类型和引用链。
不复杂但容易忽略：内存泄漏往往不是单点错误，而是多个弱引用叠加的结果。保持引用意识，配合工具验证，就能让应用长时间稳定运行。
