17370845950

JavaScript 中的内存泄漏是指本该被回收的对象因被意外持有引用而无法释放，导致内存持续增长、页面卡顿甚至崩溃；常见原因包括全局变量残留、未清除定时器、未解绑事件监听器、闭包过度捕获等。

什么是 JavaScript 中的内存泄漏

内存泄漏不是“内存用多了”，而是本该被回收的对象持续被意外持有引用，导致 GC（垃圾回收器）无法释放它。这些对象长期驻留堆中，随着应用运行时间增长，占用内存不断攀升，最终可能引发页面卡顿、崩溃或 OutOfMemoryError 类似表现。

常见泄漏场景与修复方式

多数泄漏源于开发者对引用生命周期的误判。以下是最常踩坑的几类：

• 全局变量残留：比如把临时数据挂到 window 或 globalThis 上，忘记清理；或使用未声明的变量（隐式全局）
• 定时器未清除：用 setInterval 或 setTimeout 时，回调里闭包捕获了大对象，且定时器未被 clearInterval/clearTimeout 停止
• 事件监听器未解绑：给 DOM 元素添加 addEventListener 后，元素已被移除，但监听函数仍通过闭包持有着父作用域中的对象
• 闭包过度捕获：函数内定义的内部函数无意中引用了外部大数组、DOM 节点或缓存对象，而该内部函数又被长期持有（如赋值给全局变量、传入异步队列等）

如何定位内存泄漏

靠猜不行，得用工具实测。Chrome DevTools 的 Memory 面板是首选：

• 录制 Heap snapshot：在操作前后各拍一张快照，用 Comparison 视图筛选“Detached DOM tree”或持续增长的 Array/Object 实例
• 用 Allocation instrumentation on timeline 模式跑操作，观察哪些构造函数在反复分配却没被回收（重点关注 Closure、HTMLDivElement 等）
• 注意 Retainers 列：右键泄漏对象 → “Reveal in Summary view”，看谁在强引用它——往往就是那个忘了 removeEventListener 或 clearInterval 的地方

写代码时的关键防御习惯

预防比排查便宜得多。这几条习惯能挡住 80% 的泄漏：

• 避免直接往 window 写属性；非用不可时，用完立刻 delete window.xxx
• 所有 setInterval 必须配对 clearInterval，推荐封装成可销毁的类或用 AbortController（配合 setTimeout 的 Promise 化）
• 为 addEventListener 的监听函数保留引用，以便后续 removeEventListener；不要用匿名函数
• 组件卸载（如 React 的 useEffect cleanup、Vue 的 beforeUnmount）时，显式清理定时器、事件、观察者（MutationObserver）、WebSocket 连接等副作用
• 缓存对象（如 Map 或 WeakMap）优先用 WeakMap 存储 DOM 节点 → 它不阻止 GC，天然防泄漏

const cache = new WeakMap();
function processNode(node) {
  if (cache.has(node)) return cache.get(node);
  const result = expensiveCalc(node);
  cache.set(node, result); // node 被回收时，entry 自动消失
  return result;
}

闭包本身不危险，危险的是闭包捕获了不该长期持有的东西。每次写内部函数前，问一句：这个函数会被谁持有？它需要访问外部哪些变量？那些变量的生命周期是否和它匹配？