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% 的泄漏：
立即学习“Java免费学习笔记（深入）”；
- 避免直接往
window写属性；非用不可时，用完立刻delete window.xxx - 所有
setInterval必须配对clearInterval，推荐封装成可销毁的类或用AbortController（配合setTimeout的 Promise 化） - 为
addEventListener的监听函数保留引用，以便后续removeEventListener；不要用匿名函数 - 组件卸载（如 React 的
useEffectcleanup、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;
}
闭包本身不危险，危险的是闭包捕获了不该长期持有的东西。每次写内部函数前，问一句：这个函数会被谁持有？它需要访问外部哪些变量？那些变量的生命周期是否和它匹配？
