JS 内存焦虑？聊聊那些真正有用的 GC 原理与避坑指南

打开浏览器点开几个标签页，刷了一整天网页后，电脑突然变得卡顿，风扇狂转。这时候很多人第一反应是怀疑网络或本地配置，但大概率是内存告急。很多前端开发者对 GC（垃圾回收）的理解还停留在“自动管理，无需操心”的阶段，可一旦项目变大，内存泄漏就像隐形的杀手，让应用寿命大打折扣。想解决这个问题，得先摸清垃圾回收的底层脾气。

变量到底存在哪儿？通俗来说，基础数据类型存放在栈内存里，就像办公桌面的便利贴，存取快且用完即焚；而复杂对象则住在堆内存中，相当于大型仓库里的柜子，空间大但管理成本高。GC 的主要战场就在这堆空间里。现代引擎（如 V8）普遍采用标记清除算法。它的逻辑并不神秘：每次回收前，引擎会从一组被称为“根”的对象（通常是全局对象 window、当前执行上下文等）开始遍历，把能被访问到的所有对象都打上“保留”标记，剩下的没被标记的，就会被视为垃圾统一清理。这套机制解决了旧版引用计数法无法处理循环引用的痛点，哪怕 A 引用 B、B 又反向引用 A，只要它们都脱离根节点的管辖，照样会被当作废弃品处理。

不过，为了追求极致的运行速度，V8 还引入了分代收集策略。它基于一个经验假设：绝大多数对象都是“朝生暮死”的。因此，堆内存被划分为新生代和老生代。新创建的对象先进入新生代，那里空间小、回收频率高；只有那些经历了多次回收依然存活的对象，才会晋升到老生代。这种策略避免了每次回收都要扫描整个堆，大大减少了页面卡顿的概率。你在 Chrome 性能面板里看到的频繁 Minor GC，很多时候属于正常机制，不必过度紧张，真正要警惕的是老年代内存随时间线性持续增长。

了解了原理，重点就得落在实战避坑上了。闭包往往是内存泄漏的重灾区。如果一个内部函数引用了外部作用域的大数据对象，且该函数被作为回调长期保存，那么外部的数据就无法被释放。另一个高频故障点是DOM 操作与事件绑定。比如在某个组件内给 DOM 绑定了点击事件，当组件被销毁移除 DOM 树后，如果忘记解除事件监听，或者定时器没有清除，JavaScript 引擎会认为该对象仍被外部引用，导致这块内存永远无法回收。此外，调试时随手打印的 console.log 也可能引发问题，某些情况下它会保持对对象及其子对象的引用。

排查内存问题的最佳工具是 Chrome DevTools 中的 Memory 面板。通过记录 Heap Snapshot（堆快照），你可以对比两次快照之间新增了什么对象，或者统计特定类型的对象数量是否异常暴涨。修复方案通常很直接：不用的对象引用手动置为 null，组件卸载时解绑事件和清除定时器，避免将大型数组挂在窗口全局变量上。

归根结底，现代 JavaScript 引擎的 GC 能力已经非常强悍，常规业务场景下完全不需要手写内存管理逻辑。但对于涉及大规模数据处理、长时间运行的后台服务或复杂 SPA 应用，掌握这些原理能帮你在架构设计初期就规避风险。技术选型固然重要，但懂得何时介入、如何监控，才是区分普通开发与高手的关键。别让潜在的内存泄漏，成为你上线路上的绊脚石。