generator本质是v8显式冻结/重建执行上下文，yield触发堆分配生成suspended execution context；async/await则是状态机+闭包捕获，栈帧销毁后变量靠闭包存活，内存开销源于promise链与逃逸变量。
要真正看透 Generator 相比普通异步机制（如 Promise 链、async/await）在内存和栈帧上的差异，不能只看 JS 表层写法，得下钻到 V8 的字节码层——因为 Generator 的暂停/恢复本质是 Ignition 解释器对执行上下文的显式冻结与重建，而 async/await 是语法糖，底层仍依赖 Promise + 状态机 + 闭包捕获，两者内存行为完全不同。
Generator 字节码暴露“挂起即堆分配”的硬事实
用 --print-bytecode 运行含 yield 的函数，你会看到：
-
每个 yield 指令后紧跟一个
Return或Suspend字节码，这不是简单跳转，而是触发 V8 将当前 Ignition 栈帧（含所有 slot 值、accumulator 内容、作用域链指针）序列化为一个堆对象； - 生成的字节码中会显式引用一个隐藏的
context槽位，该槽位指向老生代堆中持久化的 Suspended Execution Context 结构； - 对比普通函数：无 yield 的函数字节码里没有
Suspend，退出时直接清空 Ignition 栈帧，不产生堆对象。
async/await 字节码揭示“闭包逃逸”才是内存主因
async 函数编译后，V8 会把它重写为状态机函数（类似 function _asyncFn() { switch(state) { ... } }），其字节码特征是：
-
大量
LoadNamedProperty和StoreNamedProperty操作闭包变量，因为 await 后续代码需访问前面声明的let变量，这些变量被提升为闭包捕获，强制进堆； - 没有
Suspend指令，但有密集的CallRuntime（如PromiseResolveThenableJob），说明控制流移交给了 Promise 微任务队列； - 关键区别：async 函数本身退出后，其栈帧被销毁，但闭包对象（含所有 await 前的局部变量）仍存活——是否进老生代，取决于变量是否被 Promise 回调长期持有。
栈帧复用？Generator 压根不复用，async/await 也做不到
很多人误以为“Generator 暂停后恢复能复用栈”，其实完全相反：
- Generator 每次
next()调用，Ignition 都会新建一个栈帧来执行恢复逻辑，只是它会从堆中读取上次冻结的 slot 快照并加载进去——不是复用旧栈，而是“重建+填充”； - async/await 更彻底：await 触发后，当前函数栈帧立即销毁，控制权交还事件循环；后续
then回调在全新栈帧中执行，所有变量靠闭包引用维持，栈帧之间毫无关联； - V8 确实会对极简同步函数做栈帧复用（如空函数反复调用），但 Generator 和 async 函数因涉及跨事件循环状态保持，根本不在复用考虑范围内。
验证建议：用 GC 日志和堆快照交叉比对
光看字节码不够，要结合运行时数据：
- 启动 Node.js 加
--trace-gc --trace-gc-verbose，观察 Generator 实例创建后是否立即触发 Scavenge（说明进新生代），而长时间存活后是否晋升老生代（确认挂起上下文驻留）； - 在 Chrome DevTools 中录制 Heap Snapshot，搜索
Generator构造函数实例，展开看其 hidden properties，能找到[[Context]]引用——这个对象大小就是挂起状态的实际内存开销； - 对比相同逻辑的 async 版本：Snapshot 中找不到类似
[[Context]]，但会看到大量闭包对象（Closure）和 Promise 链节点，它们的 retained size 才是真实成本。
