JavaScript垃圾回收虽自动但有性能代价，频繁触发会导致主线程暂停、卡顿掉帧；内存水位高、不当引用、全局变量及老生代对象堆积均加剧GC压力。
JavaScript 垃圾回收（GC）本身是自动的，但它不是“免费”的——频繁或不当触发会直接拖慢代码执行，表现为卡顿、掉帧、响应延迟，尤其在动画、滚动、实时交互等场景中尤为明显。
GC 会暂停主线程，造成“停顿”
现代引擎（如 V8）虽采用增量标记、并行回收等优化，但 GC 仍需短暂暂停 JavaScript 执行来扫描内存。一次完整的老生代回收可能耗时几十毫秒，在 60fps 场景下，这相当于丢掉几帧。如果页面频繁分配大对象（如大量 JSON 解析、重复创建数组/对象），就会推高内存压力，触发更密集的 GC，形成恶性循环。
内存占用过高会加速 GC 频率
垃圾回收器主要根据内存使用水位触发：当堆内存接近阈值（V8 默认约 1.4GB，实际因设备而异），就会启动回收。以下写法容易快速抬升内存水位：
- 循环中反复 new Object()、[] 或 {} —— 每次都生成新对象，旧对象若未及时脱离引用链，就堆积成“垃圾”
- 缓存未设上限或未清理（如用普通对象做 Map 缓存，key 是字符串但 value 是 DOM 节点）
- 闭包意外保留大对象引用（例如事件处理函数里引用了整个数据列表）
不合理的引用关系阻碍回收
GC 只能回收“不可达”对象。只要一个对象还能从根（全局变量、调用栈、DOM 引用等）被访问到，它就不会被回收。常见阻碍回收的情况包括：
立即学习“Java免费学习笔记（深入）”；
- 未清除的定时器：setInterval 返回的 timer ID 若长期持有回调函数，而该函数又引用了外部大对象，整个链路都无法释放
- 未解绑的事件监听器：尤其是给 DOM 元素绑定匿名函数后未 removeEventListener，元素即使被移除，监听器仍存活
- 循环引用 + 强引用：两个对象互相引用，且没有其他外部引用时，标记-清除可回收；但若其中一方被全局变量或闭包强持，就变成泄漏
- 意外的全局变量：忘记用 let/const 声明，导致 data = {...} 直接挂到 window 上，永远可达
老生代回收代价远高于新生代
V8 将内存分为新生代（存放短期对象）和老生代（长期存活对象）。新生代 GC 快（Scavenge 算法），老生代 GC 慢（Mark-Sweep-Compact）。一旦对象在新生代经历多次 GC 后仍存活，就会晋升到老生代。这意味着：
- 频繁创建又长期持有的对象（如单例服务、全局配置、缓存容器）会更快进入老生代
- 一个本可快速回收的小对象，若被某个老生代对象无意引用（比如日志模块保存了某次请求的完整 payload），也会被迫滞留老生代，拉长下次 GC 时间
