JavaScript内存泄漏是指本该被垃圾回收的内存因引用未断开而长期滞留，导致页面卡顿甚至崩溃；常见原因包括意外全局变量、未清理事件监听器、未清除定时器、闭包持有大对象及DOM僵尸引用。
JavaScript内存泄漏，是指本该被垃圾回收（GC）释放的内存，因为某些引用关系未断开，导致引擎无法识别其“不可达”，从而长期滞留在内存中。它不会让变量“消失”，而是让无用的数据持续占用空间，最终拖慢页面、卡顿甚至崩溃。
常见引发内存泄漏的写法
这些看似正常的操作，恰恰是线上事故高发区：
-
意外的全局变量：函数内漏写
let/const/var，比如data = new Array(100000)，变量自动挂到window上，直到页面关闭才释放。 -
未清理的事件监听器：给DOM元素或
window添加addEventListener后，组件卸载却没调用removeEventListener，回调函数和闭包持续持有对作用域的引用。 -
忘记清除定时器：用
setInterval轮询数据时，页面跳转或组件销毁后未执行clearInterval，回调里的变量和上下文一直存活。 - 闭包不当持有大对象：外部函数返回闭包，而闭包内部引用了体积大的数组、缓存或DOM节点，即使外部函数已执行完毕，这些数据也无法被回收。
-
DOM“僵尸引用”：调用
removeChild或innerHTML = ''移除了元素，但JS中仍保留着对该DOM节点的引用（如let btn = document.getElementById('x')），节点实际未释放。
实用的检测方法
不能只靠感觉判断——要靠工具定位真实问题：
- 打开Chrome DevTools → Memory 面板 → 点击左上角录制按钮，操作页面关键路径（如打开/关闭弹窗、切换列表页），停止后点击 Collect garbage（回收站图标）强制触发GC；重复几次，观察堆内存（JS Heap）是否持续上涨且不回落。
- 使用 Performance 面板录制一段时间，重点关注“Memory”轨道：若曲线呈阶梯式上升、每次GC后基线抬高，大概率存在泄漏。
- 对比两次快照（Heap Snapshot）：先拍一张初始快照，执行疑似泄漏操作后再拍一张，用“Comparison”模式筛选出新增且未释放的大型对象（如
Array、Closure、HTMLDivElement等），顺着retainers链条往上查引用源头。
可落地的避免策略
预防比修复成本低得多，日常编码中注意这几条：
立即学习“Java免费学习笔记（深入）”；
- 所有变量声明必须带
let或const（禁用var，避免变量提升+作用域混淆）；函数内避免裸赋值。 - 绑定事件监听前，优先考虑使用事件委托；若需绑定到具体元素，确保在组件
unmount或destroy生命周期中配对调用removeEventListener。 - 定时器统一管理：用
Map或数组保存intervalId/timeoutId，在离开场景前遍历clearInterval/clearTimeout。 - 大对象与DOM绑定时，优先用
WeakMap（键名是弱引用，不影响GC）替代普通对象存储元数据。 - 创建
URL.createObjectURL后，务必在不再需要时调用URL.revokeObjectURL，否则Blob URL会一直驻留内存。
内存泄漏不是玄学，它是引用关系失控的具体表现。理解V8的标记-清除机制，盯住“谁还在引用它”，就能把问题从模糊的“卡”变成清晰的“可修复”。
