高频创建 Generator 迭代器虽不直接触发大量 GC，但因生成带状态的堆对象（含执行上下文、闭包捕获等），会加剧新生代压力与回收抖动；缓解需复用实例、避免热路径闭包捕获、显式调用 .return() 释放。
高频创建 Generator 迭代器本身不会直接触发大量 GC，但会通过隐式对象分配、闭包捕获和执行上下文膨胀，间接加剧新生代压力与回收抖动。关键不在 Generator 语法，而在它背后持续生成的不可复用执行状态。
Generator 实例本质是带状态的堆对象
每次调用 function* 返回的迭代器（如 gen()）是一个完整对象，包含：
- 内部 [[GeneratorState]] 字段（"suspended"/"closed" 等）
- 私有 [[GeneratorContext]]：保存 yield 暂停点的执行上下文（含寄存器快照、词法环境引用）
- 闭包捕获的外层变量（即使未显式使用，只要在作用域链中就可能被绑定）
这些结构全部分配在 JS 堆上，且生命周期由迭代器持有——只要没调用 .return() 或完成遍历，它就无法被回收。短命迭代器（如每次渲染循环新建一个）等于高频向新生代注入中等体积对象。
抖动根源：新生代填满 + 隐式逃逸
现代引擎（V8、SpiderMonkey）对 Generator 的优化有限，尤其当满足以下任一条件时：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
-
闭包捕获大对象：比如在 React 组件内定义
function* dataStream() { yield props.bigList; }，整个props被绑定进迭代器闭包，提前晋升至老生代 - yield 后长期不消费：迭代器暂停后闲置，其上下文持续驻留，占用内存并阻碍新生代 compact
-
嵌套 Generator 链：如
function* chain() { yield* inner(); }，每个yield*都新增一层执行帧与代理迭代器，对象数量线性增长
验证与定位方法
不用猜，用工具确认实际影响：
-
Chrome DevTools → Memory → Allocation instrumentation on timeline：开启后录制操作，筛选构造函数名
Generator或AsyncGenerator，看每秒分配量与存活对象数 -
V8 flags 检测晋升：启动 Chrome 时加
--trace-gc --trace-gc-verbose，观察日志中是否频繁出现Scavenge（新生代回收）及Move to old space记录 - Performance 面板标记 GC 事件：在录制中勾选 “Garbage Collection”，查看 GC 事件是否密集出现在 Generator 创建/调用密集区段
真正有效的缓解方式
不靠调 GC 参数，而从使用模式切入：
-
复用单实例 + 重置逻辑：对固定数据流，改用类封装状态，提供
.reset(data)和.next()方法，避免反复 new 迭代器 -
用 Array/Iterator 替代轻量场景：若只是遍历已知数组，
for...of arr或arr[Symbol.iterator]()开销远低于function*() { for (x of arr) yield x; }() -
显式释放暂停态：对可能长期挂起的迭代器，在不再需要时调用
iterator.return()，通知引擎清理上下文（V8 10.5+ 已支持该优化） - 避免在热路径闭包捕获：把需迭代的数据提前解构或复制为局部常量，而非让 Generator 直接闭包引用组件 state 或大型缓存
Generator 是强大抽象，但不是零成本语法糖。高频创建时，它暴露的是 JS 引擎对“可恢复执行”这一动态特性的固有开销。看清对象图生成逻辑，比等待 GC 优化更可靠。
