生成器的 next() 本质是复用并恢复同一栈帧，而非重建调用栈；yield 是执行流锚点，暂停时快照帧状态，后续 next() 直接从中断处继续执行，内存恒定但频繁切换可能触发引擎微任务限制。
当外部调用 next() 激活一个已暂停的生成器时，Python 解释器并不会重建传统函数调用栈，而是直接恢复保存在生成器对象内部的栈帧（frame object）——这个过程不涉及 C 层调用栈压入，而是“上下文切换”式的状态重载。
yield 不是 return，而是执行流的锚点
生成器函数被调用时，解释器仅创建生成器对象并分配一个空闲栈帧，不执行任何语句。首次 next() 触发后，解释器才将该栈帧标记为“活跃”，从函数起始逐行执行，直到遇到第一个 yield。此时：
-
yield右侧表达式求值，结果作为本次迭代返回值 - 当前栈帧（含局部变量、指令指针、异常状态等）被完整快照并挂起，绑定到生成器对象的
gi_frame属性 - 控制权立即交还调用方，Python 主执行栈清空该帧引用
next() 的本质是帧恢复指令，不是函数调用
后续每次 next() 并不重新进入函数入口，而是：
- 定位生成器对象中已挂起的
gi_frame - 将该帧状态载入解释器执行上下文（包括恢复
f_lasti指令偏移量） - 从
yield下一条字节码继续执行，而非从头开始
这解释了为什么 yield 后赋值语句（如 res = yield 4）在第二次 next() 时才真正执行：上一次暂停点就在 yield 行末，恢复后自然落到赋值操作。
微任务队列与生成器恢复无直接耦合，但影响调度节奏
微任务（如 Promise.then、queueMicrotask）本身不干预 Python 的帧恢复机制——因为那是 JS 运行时概念。但在 Python 的异步生态（如 asyncio）中，事件循环通过类似机制调度协程：
- 协程底层由生成器实现，
await等价于yield暂停 + 事件注册 - 事件循环在微任务阶段检查就绪任务，对每个就绪协程调用其
send()或throw()，触发帧恢复 - 若恢复后的生成器又立刻
yield并注册新微任务，就可能形成密集帧切换链，虽不增长 C 栈，但会加重解释器上下文切换开销
关键区别：栈帧 vs 调用栈
普通函数递归会不断压入新栈帧，最终触发 RecursionError；而生成器的多次 next() 始终复用同一个栈帧，只是反复激活/挂起它。因此：
- 内存占用恒定，与迭代次数无关
- 没有传统“调用栈越界”，但频繁恢复可能暴露引擎对连续微任务链的限制（如 V8 的 microtask queue 深度防护）
- 真正危险的是在微任务中无条件链式调用
next()，造成逻辑上的同步递归假象，而非物理栈溢出
