JavaScript内存泄漏因未释放内存导致性能下降，常见原因包括全局变量、未清理事件监听、闭包引用、定时器、DOM引用和缓存无上限；可通过Chrome DevTools的堆快照、分配时间线等工具对比分析，查找并修复泄漏点。
JavaScript内存泄漏是指程序在运行过程中分配的内存没有被及时释放，导致可用内存逐渐减少，最终可能引起页面卡顿甚至崩溃。这类问题在长期运行的单页应用（SPA）中尤为常见。要有效解决内存泄漏，必须先理解其常见原因，再结合工具进行排查和修复。
常见的JavaScript内存泄漏原因
了解泄漏源头是解决问题的第一步。以下是几种典型的内存泄漏场景：
-
意外的全局变量：未声明的变量会自动成为全局对象（如window）的属性，始终驻留在内存中。
-
未清理的事件监听器：DOM元素被移除后，若仍绑定事件监听器，该元素及其回调函数无法被回收。
-
闭包引用不当：闭包持有外部函数变量的引用，若内部函数被长期保留，外部变量
也无法释放。
-
定时器（setInterval / setTimeout）：回调函数中引用了外部对象，而定时器未清除，导致对象一直存活。
-
DOM引用未释放：JavaScript中保留了对已从文档移除的DOM节点的引用，形成“孤立节点”泄漏。
-
缓存未设上限：使用对象或Map做缓存时，若不控制大小或不设置过期机制，数据会无限增长。
使用Chrome DevTools排查内存泄漏
Chrome开发者工具提供了强大的内存分析功能，帮助定位泄漏点：
-
Memory面板 - Heap Snapshots（堆快照）：在关键操作前后手动拍摄堆快照，对比对象数量变化，查找异常增长的构造函数或DOM节点。
-
Record Allocation Timeline（内存分配时间线）：实时记录内存分配情况，可观察哪些操作产生了大量短期对象或长期未释放的对象。
-
Performance面板录制**：记录页面运行时性能数据，查看内存曲线是否持续上升，结合调用栈定位可疑代码。
-
Detached DOM trees检测**：在堆快照中搜索“Detached”关键字，找到已脱离DOM但仍被JS引用的节点。
实际排查步骤示例
假设发现页面长时间运行后变慢，怀疑存在内存泄漏，可按以下流程操作：
- 打开Chrome DevTools，切换到Memory面板。
- 选择Heap snapshot模式，点击“Take Snapshot”记录初始状态。
- 执行疑似泄漏的操作（如打开关闭某个模块多次）。
- 再次拍摄堆快照，重复几次操作后拍摄第三个快照。
- 在快照列表中选择最后一个，将Summary视图切换为Comparison模式，与第一个快照对比。
- 关注Delta列中数值持续增加的对象，特别是自定义构造函数、Closure、HTMLDivElement等类型。
- 展开具体对象，查看右侧的retaining tree（引用链），找出是谁持有了这些对象的引用。
常见修复策略
根据排查结果，采取对应的修复手段：
- 确保变量使用
var、let或const声明，避免污染全局作用域。
- 移除DOM前，调用
removeEventListener清理所有事件监听。
- 定时器在组件销毁时通过
clearInterval或clearTimeout清除。
- 对DOM引用的变量，在不再需要时手动置为
null。
- 使用WeakMap或WeakSet存储关联数据，它们不会阻止垃圾回收。
- 为缓存机制添加大小限制或LRU淘汰策略。
基本上就这些。内存泄漏不易察觉，但通过定期监控和良好编码习惯可以有效避免。关键是建立在开发和测试阶段主动检查内存行为的意识。工具虽强，预防胜于治疗。
也无法释放。