JavaScript内存泄漏主因是开发者无意保留引用，GC无法回收仍被引用的对象；核心机制为标记-清除算法，从根对象出发标记存活对象，未标记者被清除；常见泄漏模式有全局变量残留、未清理事件监听器、未清除定时器、闭包意外保留大对象引用。
JavaScript 的内存泄漏往往不是因为语言本身不回收内存，而是开发者无意中保留了本该被释放的引用。垃圾回收（GC）自动运行，但无法清理“仍被引用”的对象——哪怕你已不再需要它。关键在于理解 GC 如何判断“可回收”，以及哪些常见模式会意外延长对象生命周期。
垃圾回收的核心机制：标记-清除（Mark-and-Sweep）
现代 JavaScript 引擎（如 V8）主要使用标记-清除算法：
- 从一组称为“根”（roots）的对象开始追踪，比如全局对象、当前执行函数的局部变量、栈中活跃的引用等；
- 递归标记所有能从根访问到的对象为“存活”；
- 未被标记的对象被视为不可达，随后被清除并释放内存。
注意：引用计数（如早期 IE）已被弃用，因为它无法处理循环引用（A → B 且 B → A），而标记-清除天然规避此问题。
最常导致内存泄漏的 4 种写法
1. 全局变量残留
显式或隐式创建的全局变量永远不会被 GC 回收。
- 避免
myData = [...]（漏掉var/let/const）； - 定时器回调里意外赋值到
window或globalThis； - 模块顶层的大型数组/对象应确保有明确的销毁逻辑。
2. 未清理的事件监听器
DOM 元素被移除，但绑定的 handler 仍持有对它的引用（尤其用箭头函数或闭包时）。
- 用
element.addEventListener()后，记得在元素销毁前调用removeEventListener()； - 对动态创建的组件，统一在卸载（如 React 的
useEffect cleanup、Vue 的beforeUnmount）中解绑； - 考虑使用
{ once: true }选项，适合只触发一次的监听。
3. 定时器未清除（setInterval/setTimeout）
回调函数形成闭包，持续引用外部作用域变量，即使相关 DOM 已消失。
- 始终保存定时器 ID（
const id = setInterval(...)），并在不需要时调用clearInterval(id)； - 在单页应用中，页面切换或组件卸载时务必清理；
- 避免在闭包中引用大型对象（如整个 Vue 实例、React state）。
4. 闭包中意外保留大对象引用
闭包让内部函数能访问外层作用域变量，但如果这个变量是大型数据结构，又没被及时置空，就会滞留。
- 检查回调函数是否真的需要访问全部外层变量；
- 必要时手动切断引用：
largeObj = null； - 避免在频繁触发的回调（如
scroll、resize）中创建新闭包并缓存大对象。
如何发现和验证内存泄漏
仅靠代码审查不够，需借助工具定位：
- Chrome DevTools → Memory 面板 → 拍摄堆快照（Heap Snapshot），筛选“Constructor”查找异常增长的类（如
Closure、Array、自定义类）； - 录制内存时间线（Record Allocation Timeline），观察 JS 堆是否随操作持续上升且不回落；
- 对比两次快照，用 “Retainers” 查看谁持有着目标对象（即“为什么没被回收”）；
- 在 Node.js 中可用
process.memoryUsage()监控 RSS 和 heapUsed 变化趋势。
实用建议：防御性编码习惯
不是所有泄漏都要立刻修复，但以下习惯能大幅降低风险：
- 组件/模块销毁时，统一做“清理清单”：清定时器、解监听、断开 WebSocket、释放 canvas 上下文；
- 避免在函数内直接给全局对象挂属性，改用模块级变量 + 显式管理生命周期；
- 用 WeakMap / WeakSet 存储与对象关联的元数据（它们不阻止 GC，适合缓存、状态映射）；
- 对大型数据结构（如日志缓冲区、历史记录），设置容量上限并自动淘汰旧项。
垃圾回收不是黑箱，它是基于可达性的确定性过程。真正决定内存命运的，是你写的那几行“还留着引用”的代码。看清谁在引用、何时该断开，比背算法更重要。
