JavaScript内存管理依赖自动垃圾回收，但开发者仍需防范泄漏。1. 避免意外全局变量，使用严格模式；2. 及时清理定时器和事件监听；3. 控制闭包引用大对象；4. 解除已移除DOM的引用。借助Chrome DevTools分析堆快照与内存趋势，可有效检测泄漏。良好编码习惯是关键。
JavaScript的内存管理是开发者必须理解的核心机制之一。虽然它具备自动垃圾回收功能，但并不意味着可以完全忽视内存使用问题。了解其工作原理并掌握常见内存泄漏的防范方法，对提升应用性能至关重要。
垃圾回收机制的基本原理
JavaScript引擎会自动管理内存分配与释放。当变量不再被引用时，垃圾回收器（Garbage Collector）会将其占用的内存回收。
主流的垃圾回收算法包括：
- 标记清除（Mark-and-Sweep）：从根对象（如全局对象）出发，遍历所有可达对象并标记，未被标记的对象被视为垃圾。
- 引用计数（Reference Counting）：跟踪每个值被引用的次数，引用为0时立即释放。但由于循环引用的问题，现代引擎已较少单独使用。
V8引擎主要采用分代回收策略，将堆内存分为新生代和老生代，针对不同生命周期的对象采用不同的回收算法，提高效率。
立即学习“Java免费学习笔记（深入）”；
常见的内存泄漏场景及防范
尽管有自动回收机制，不当的代码仍会导致内存无法释放，造成泄漏。以下是几种典型情况：
1. 意外的全局变量未声明的变量会成为全局对象的属性，长期驻留内存。
示例：
function leak() {
leakedVar = 'I am global now'; // 忘记用 var/let/const
}
解决：使用严格模式（"use strict"），让此类错误抛出异常。
2. 未清理的定时器或事件监听setInterval、setTimeout 或 DOM 事件监听若未及时清除，会持续持有回调函数及其作用域。
建议：
- 组件销毁时调用 clearInterval、clearTimeout。
- 使用 addEventListener 的同时，在适当时机调用 removeEventListener。
闭包会保留对外部变量的引用，若外部作用域包含大量数据且闭包长期存在，可能导致内存堆积。
优化：避免在闭包中长期持有大型数据结构，使用完成后手动置 null。
4. 被遗忘的 DOM 引用即使 DOM 元素已被移除，若 JavaScript 中仍有对其的引用，该元素不会被回收。
例如：
let element = document.getElementById('myDiv');
// 后续删除了该元素但仍保留在变量中
element = null; // 手动解除引用
检测与调试内存问题
Chrome DevTools 提供了强大的内存分析工具：
- Memory 面板：可拍摄堆快照（Heap Snapshot），查看当前对象的内存分布。
- Performance 面板：记录运行时内存变化，观察内存增长趋势。
- Allocation instrumentation on timeline：追踪对象分配过程，定位泄漏源头。
通过对比多个快照，查找“本应被释放却依然存在”的对象，是排查泄漏的有效方式。
基本上就这些。掌握垃圾回收机制，养成良好的编码习惯，定期检查关键模块的内存行为，能有效避免大多数问题。不复杂但容易忽略。
