JavaScript 会出现内存泄漏问题。尽管现代 JavaScript 引擎（如 V8）拥有强大的自动垃圾回收机制（Garbage Collection, GC），但这并不意味着开发者可以完全高枕无忧。内存泄漏通常发生在代码无意中持有了对不再需要的对象的引用，导致垃圾回收器无法识别并回收这些内存。随着应用程序运行时间的推移，这些未释放的内存会不断累积，最终导致页面卡顿、性能下降，甚至浏览器崩溃。理解内存泄漏的成因，是编写高性能、长生命周期应用（如单页应用）的必修课。
一、垃圾回收机制与内存泄漏的本质
要理解内存泄漏，首先要理解 JavaScript 的内存管理。JS 引擎主要通过**标记-清除（Mark-and-Sweep）**算法来管理内存。当一个变量进入执行环境时，它被标记为“活跃”；当离开环境时，它被标记为“可回收”。垃圾回收器会定期扫描内存，清除那些不再被根（如全局对象 window）引用的对象。
内存泄漏的本质，就是“该被回收的对象依然被引用”。只要存在一条从根对象出发的引用链指向该对象，垃圾回收器就会认为该对象是“活跃”的，从而保留其占用的内存。这种引用往往是隐蔽的，开发者在逻辑上认为对象已经“死”了，但在代码层面却依然“活”着。
二、常见的内存泄漏场景
1. 意外的全局变量
这是最基础但也最容易被忽视的泄漏源。在 JavaScript 中，如果给一个未声明的变量赋值，它会自动挂载到全局对象（浏览器中是 window）上。全局变量在页面关闭前都不会被回收。
例如，在函数内部直接赋值 data = 'huge string' 而忘记加 var/let/const，这个巨大的字符串就会一直驻留在内存中。开启 'use strict' 严格模式可以有效避免此类问题。
2. 被遗忘的定时器与回调
setInterval 和 setTimeout 是常用的定时工具。如果定时器内部引用了外部的大对象（如 DOM 节点或大型数组），且定时器没有被及时清除（clearInterval），那么这些外部对象就无法被回收。
特别是在单页应用中，如果组件卸载时忘记清除定时器，该组件占用的内存就会一直被定时器“扣住”，导致严重的泄漏。
3. 闭包的不当使用
闭包是 JS 的强大特性，但也容易引发泄漏。闭包会保留对其父作用域变量的引用。如果闭包生命周期过长，或者被赋值给全局变量，那么它所引用的父级变量（即使是大对象）也无法被释放。
例如，一个返回内部函数的外部函数，如果内部函数引用了外部的大数组，只要这个内部函数还在被使用，那个大数组就无法被回收。
4. DOM 引用与事件监听器
这是前端开发中最常见的泄漏场景。
- 脱离 DOM 的引用：当你从 DOM 树中移除一个元素（
removeChild），但 JavaScript 代码中依然有一个变量指向它，那么这个元素及其子元素、事件监听器都不会被回收。 - 未移除的事件监听器：给 DOM 元素添加事件监听器（
addEventListener）后，如果该元素被移除或页面跳转，但没有调用removeEventListener，监听器及其闭包引用的变量就会一直存在。这在频繁创建和销毁组件的 SPA 中尤为致命。
5. 集合类对象的不当管理
使用 Map 或 Set 存储对象引用时，如果只将键（Key）置为 null 而没有从集合中删除该条目，对象依然会被集合引用而无法回收。
例如，map.set(obj, value) 后，若只执行 obj = null，Map 内部依然持有原对象的引用。此时应使用 WeakMap 或 WeakSet，它们对键的引用是“弱引用”，不会阻止垃圾回收。
6. 控制台日志引用
这是一个容易被忽视的细节。在 Chrome 开发者工具中，console.log() 如果打印了一个对象，开发者工具可能会为了让你在控制台展开查看该对象，而保持对该对象的引用。如果在生产环境代码或调试结束后忘记清理这些 console 语句，可能会导致内存无法释放。
三、如何排查与预防
排查内存泄漏最有效的方法是使用 Chrome DevTools 的 Memory 面板。通过录制内存快照（Heap Snapshot）并对比不同时间点的快照，可以清晰地看到哪些对象数量在异常增加，以及是谁在引用它们（Retainers）。
预防方面，建议遵循以下最佳实践：
- 严格模式：始终使用
'use strict'。 - 及时清理：组件卸载时，务必清除定时器、移除事件监听器、断开 DOM 引用。
- 弱引用：对于缓存或临时映射，优先使用
WeakMap和WeakSet。 - 避免全局：尽量减少全局变量的使用，缩小变量作用域。
掌握这些知识，能帮助你在构建大型应用时，有效避免内存“虚高”的尴尬，确保应用流畅运行。
