v8分代回收机制将“对象大多活不久”的规律转化为内存管理逻辑，新生代专为短命对象设计，采用scavenge复制算法实现毫秒级回收、零碎片，并设严格晋升门槛；优化关键在于让对象“出生即孤立”。
V8 引擎的分代回收机制，本质是把“对象大多活不久”这个真实规律，直接变成内存管理的底层逻辑。对短生命周期对象来说，它不是锦上添花的优化，而是从分配那一刻起就设计好的快车道。
新生代就是为短命对象量身定制的
V8 默认把新创建的对象（比如 []、{}、函数内临时变量、闭包捕获的小值）放进新生代（New Space），这个区域很小（通常 1–8 MB），但回收极快。关键不在于“小”，而在于它用的是 Scavenge 复制算法：只扫描存活对象，复制过去就完事，其余空间直接清空。这意味着——
- 90% 以上刚分配就失去引用的对象，根本不用被“扫描”到，自然消失
- 不需要遍历整个堆，停顿时间控制在毫秒级以内
- 内存布局天然紧凑，几乎不产生碎片
晋升门槛严控，防止短命对象“误入老年代”
一个对象要离开新生代，得满足两个硬条件之一：
- 在两次 Scavenge 回收中都存活下来（默认阈值）
- 复制到 To 空间时发现占用超过 25%，立刻晋升（防 To 空间过载）
这相当于给短命对象设了“生存考试”：没真活够两轮，就不许进老生代。一旦被静态字段、闭包、事件监听器意外强引用，它就会反复被复制、卡在晋升路上，拖慢新生代 GC 效率——所以真正有效的优化，是写代码时让对象“出生即孤立”，比如：
- 避免把
Array或Object缓存在模块级变量里 - 循环内拼接字符串用
StringBuilder（Node.js）或数组push + join，而不是+= -
async函数里少定义大块局部数据，防止编译器生成的状态机类把它们全打包成字段
第 0 次 GC 就能清理，不需要等全堆扫描
新生代 GC（Minor GC）触发条件很轻：From 空间一满就扫。不像老生代 GC（Major GC）要等内存压力累积、标记-清除跑完整个堆。这意味着——
- 每次 HTTP 请求产生的临时解析结构（如 JSON.parse 结果、中间 map）、表单校验对象，大概率在请求结束前就被清掉
- 即使你没手动调 gc，V8 也在后台高频、低开销地做这件事
- 如果观察
--trace-gc输出，Scavenge 日志远多于 Mark-sweep，说明短命对象正按预期流动
不复杂但容易忽略
