JavaScript内存泄漏指本该回收的内存未释放，导致内存持续增长甚至崩溃；常见原因包括全局变量意外挂载、未清理事件监听器、定时器未清除、闭包过度捕获及缓存无上限；预防需遵循“谁创建谁清理”，排查依赖Chrome Memory面板堆快照与引用链分析。
JavaScript 的内存泄漏是指本该被回收的内存没有被及时释放，导致内存占用持续增长，最终可能拖慢页面甚至崩溃。它不像后端服务那样容易被监控，但前端长期运行的单页应用（SPA）、富交互组件或定时任务多的场景中特别常见。
哪些操作容易引发内存泄漏？
不是所有变量不手动清除都会泄漏，关键看是否还存在活跃的引用链阻止垃圾回收器（GC）回收。常见高危模式有：
-
全局变量意外挂载：比如忘了写
var/let/const，直接赋值data = {...}，变量会挂在window上，永远存活 - 未清理的事件监听器：给 DOM 元素绑定事件，但元素已被移除，监听函数仍通过闭包持有对外部数据的引用
-
定时器未清除：
setInterval或setTimeout的回调里引用了外部大对象，且定时器没clearInterval，回调一直存在，引用链就断不了 - 闭包过度捕获：函数内部返回另一个函数，而这个函数无意中保留了对大数组、DOM 节点或整个组件实例的引用
- 缓存未设上限或未清理：比如用对象做 Map 缓存请求结果，key 不断增加又不淘汰旧项，内存只增不减
怎么避免内存泄漏？
预防比修复更高效。核心原则是：谁创建，谁负责清理；引用越短，风险越低。
- 组件卸载（如 React 的
useEffect清理函数、Vue 的beforeUnmount）时，主动removeEventListener、clearTimeout/clearInterval - 避免在事件回调或定时器中直接引用大型数据结构；必要时用弱引用（如
WeakMap存缓存，键是对象，不阻止 GC） - 用现代 API 替代易出错的手动管理：比如用
AbortController控制fetch生命周期，响应取消自动清理 - 全局状态尽量走集中管理（如 Redux、Pinia），而不是散落在各处的全局变量或模块级常量
- 开发阶段开启 Chrome 的
Memory面板，定期录制“Allocation instrumentation on timeline”，观察是否有持续增长的新生代对象
怎么排查已发生的内存泄漏？
靠猜不行，得用工具定位“谁活着，为什么活”。Chrome DevTools 是主力：
立即学习“Java免费学习笔记（深入）”；
- 打开 Memory 面板 → 点击 Record Allocation（或选 “Heap snapshot”）→ 操作疑似泄漏的流程（比如打开关闭某个模态框 3 次）→ 停止录制
- 对比多个快照：筛选
Constructor列，找数量异常增多的类型（如Closure、Array、自定义类名）；点开看其 Retainers（保留者），找到维持它存活的引用路径 - 重点关注
Detached DOM tree：说明 DOM 节点已被移除，但 JS 还有引用（比如事件监听器、jQuery 缓存、Vue 实例没销毁） - 配合 Performance 面板 录制长任务，看内存曲线是否阶梯式上涨，再结合堆快照交叉验证
补充：Node.js 环境注意什么？
服务端泄漏后果更严重，一次泄漏可能撑爆整个进程。除了前端常见问题，还要警惕：
-
require缓存导致模块无法 GC（尤其动态require+ 大文件） - 未关闭的数据库连接、Redis 客户端、文件流（
fs.createReadStream） - 用
process.on('uncaughtException')吞异常却不退出，让错误状态持续累积 - 推荐用
node --inspect+ Chrome DevTools 连接调试，或使用heapdump模块生成快照分析
基本上就这些。内存泄漏不复杂，但容易忽略细节。养成“用完即清”的习惯，配合工具定期扫描，90% 的问题都能提前掐掉。
