generator不增加原生调用栈帧，而是用堆上生成器对象替代，物理栈深度恒定为1；其字节码含yield_value指令、无连续call_function嵌套，而async/await依赖事件循环调度，导致隐式栈帧复用与更深调用链。
直接看字节码就能判断 Generator 在调用栈深度上的资源开销——它不增加原生调用栈帧，而是用堆上生成器对象替代栈帧压入，物理栈深度恒定为 1（或仅含顶层入口帧），和纯异步架构（如基于 Promise 链或事件循环回调）有本质区别。
Generator 的字节码不推栈，只建对象
Python 中 yield 函数编译后，CALL_FUNCTION 不会触发传统栈帧嵌套；取而代之的是 GET_ITER + FOR_ITER 或显式 YIELD_VALUE 指令。解释器在首次调用时创建一个 generator 对象（分配在堆上），其内部封装了代码对象、局部变量快照、指令指针（f_lasti）和状态机字段（gi_state）。后续每次 next() 或 send() 只是恢复该对象的执行上下文，不新增 CPython 调用栈帧。
- 用
dis.dis(gen_func)查看字节码，找不到连续的CALL_FUNCTION嵌套序列，只有单次入口 + 多次YIELD_VALUE和跳转指令 - 对比普通递归函数：后者每层调用都生成新
PyFrameObject并压入 C 栈，栈深度随层数线性增长，可能触发RecursionError - Generator 即使“递归式” yield 1000 次，CPython 的 C 调用栈深度仍为 2（
main → gen_func），不会溢出
纯异步架构依赖真实栈展开与回调注册
Promise 链或 async/await 在 Python 中底层仍需调度器介入：每次 await 表达式求值后，控制权交还事件循环，当前协程被挂起，栈帧被保存到 coro 对象中；但当回调被事件循环重新调度时，会重建新的栈帧（哪怕逻辑上是“继续执行”）。尤其在嵌套 await 场景下，多个 await 表达式可能触发多层回调注册，导致：
- 事件循环内部维护大量
Future或Task对象，每个都携带栈帧快照（虽非 C 栈，但占堆内存） - 异常传播路径更长：从底层
await抛出，需经多层__await__、send()、throw()调用链回溯，实际调用栈深度可能达 5–8 层 - 用
sys._current_frames()或tracemalloc可观测到大量coroutine和Future实例驻留堆中，而 generator 对象数量稳定且结构轻量
关键差异在栈帧生命周期管理方式
Generator 的栈帧（PyFrameObject）在首次调用后即冻结并托管给生成器对象，不再参与常规函数返回流程；而 async 函数每次 await 后的恢复，本质是事件循环调用 coro.send()，这会重新激活一个已存在的协程帧——但该帧的 f_back 指针仍指向事件循环调度器帧，形成隐式调用链。
- Generator：栈帧“休眠”在堆对象内，C 栈无增长，内存占用≈单帧 + 少量状态字段（约 200–400 字节）
- Async：每个活跃
Task维护完整帧链快照，且调度器自身帧始终在栈顶，物理栈深度取决于调度嵌套层级 - 实测验证：对同一逻辑写 generator 版和 async 版，在高并发 yield/await 场景下，前者
threading.stack_size()稳定，后者len(inspect.getouterframes())明显更深
字节码层面识别低栈深的关键信号
分析 dis.dis() 输出时，关注三类指令组合：
- 出现
YIELD_VALUE或YIELD_FROM：表明控制流主动让出，不依赖外部调度器，栈不增长 - 无连续
CALL_FUNCTION+POP_TOP循环：说明没有靠函数调用模拟状态机，避免栈累积 - 存在
GET_AWAITABLE+LOAD_METHOD（如send）：这是 async 恢复机制标志，意味着帧需被事件循环再次压栈调度
本质上，Generator 是用堆换栈，async 是用调度器协调栈帧复用——前者物理栈深度可控，后者逻辑简洁但栈资源消耗更隐蔽。
