JavaScript内存泄漏指本该回收的内存未被GC释放，导致堆内存持续增长、页面卡顿甚至崩溃；常见原因包括意外全局变量、未清理事件监听器、未清除定时器、闭包持有大对象及DOM僵尸引用，需通过Chrome Memory面板检测并结合严格编码习惯预防。
JavaScript内存泄漏，是指本该被释放的内存没有被垃圾回收机制（GC）回收，导致无用对象持续占用内存，JS堆大小随时间不断增长。它不会立刻出问题，但长期运行后会拖慢页面、卡顿，严重时直接崩溃。
常见内存泄漏场景及避免方法
以下五类写法在实际项目中最容易引发泄漏，修复成本低但影响大：
-
意外的全局变量：函数内漏写
let/const/var，如data = new Array(1e6)，变量自动挂到window上，永不释放。解决方法：严格启用"use strict"，或局部声明+用完置null。 -
未清理的事件监听器：给DOM元素添加
addEventListener后，元素被移除却没调用removeEventListener；尤其监听window或document时更危险。解决方法：组件卸载时统一解绑，React可用useEffect返回函数，Vue可用onBeforeUnmount。 -
定时器未清除：
setInterval或setTimeout创建后，页面跳转或组件销毁仍持续执行。解决方法：保存定时器ID（如const timer = setInterval(...)），并在退出逻辑中调用clearInterval(timer)。 -
闭包长期持有大对象：闭包引用了外部的大数组、大对象，且该闭包又被全局变量或长生命周期对象（如缓存Map）持有。解决方法：改用
WeakMap存储关联数据，或业务结束后主动将闭包引用置为null。 -
DOM“僵尸引用”：调用
removeChild或innerHTML = ''移除了元素，但JS代码中仍保留对该DOM节点的引用（如const btn = document.getElementById('x')未清空）。解决方法：移除后手动设btn = null，或用WeakRef+FinalizationRegistry做兜底清理。
如何检测内存泄漏
靠肉眼观察不行，得借助Chrome DevTools的内存分析能力：
- 打开开发者工具 → Memory 面板 → 选择 Heap snapshot 或 Allocation instrumentation on timeline；
- 先刷新页面，录制一次快照作为基线；
- 执行疑似泄漏的操作（如反复打开关闭某个模块）；
- 再录制2–3次快照，对比对象数量和构造函数实例是否持续增长；
- 点击右上角 Collect garbage（回收站图标）强制触发GC，若堆内存仍不回落，大概率存在泄漏；
- 重点关注
Closure、HTMLDivElement、Array等类型是否异常堆积，点开查看保留路径（Retaining Path），定位谁在持有着它。
日常开发中的预防习惯
防患于未然比事后排查更高效：
立即学习“Java免费学习笔记（深入）”；
- 所有异步资源（定时器、事件监听、Observer、Web Worker）都配套清理逻辑；
- 避免在闭包中直接引用大型数据结构，优先用ID或键名代替实体对象；
- 使用
URL.createObjectURL后，务必在不需要时调用URL.revokeObjectURL； - 大型单页应用中，对缓存对象（如
Map、Set）设置生命周期管理，定期清理过期项； - CI流程中可接入
heapdump或node --inspect做自动化内存巡检（适用于Node.js服务端场景）。
内存泄漏不是玄学，是可预见、可定位、可修复的问题。关键在于建立对引用关系的敏感度，以及把清理逻辑当作和创建逻辑一样重要的编码责任。
