Python生成器系统学习路线第567讲_核心原理与实战案例详解【指导】_技术教程

Python生成器是协程调度的底层载体，其核心是状态机机制：yield为暂停点，next()恢复执行至下一yield，send()注入值，throw()抛异常，yield from实现委托协议，生成器耗尽后不可重用。

Python 生成器不是“语法糖”，而是协程调度的底层载体；不理解 yield 的状态机本质，就无法真正用好 async/await。

为什么 `next()` 会触发 `yield` 但不执行下一行？

因为 yield 不是返回值的终点，而是暂停点：解释器把函数体编译成状态机，每次调用 next() 就恢复到上次暂停的位置（即 yield 行），继续执行直到下一个 yield 或函数结束。

yield 表达式本身返回值由 send() 传入，首次调用必须用 next() 或 send(None)
函数内有 yield 就自动变成 generator function，调用它返回的是 generator 对象，不是执行函数体
生成器对象第一次调用 next() 时，会运行到第一个 yield 并暂停，此时函数栈帧被挂起并保存在生成器对象内部

`send()` 和 `throw()` 怎么打破单向数据流假象？

生成器常被误认为只能“往外吐值”，其实它能双向通信：send(value) 把值注入暂停点，作为当前 yield 表达式的返回值；throw() 则在暂停位置抛出异常——这正是 asyncio 实现事件循环的基础机制。

send() 必须在生成器已启动（即已调用过 next()）后使用，否则报 TypeError: can't send non-None value to a just-started generator
yield 可以单独写（等价于 yield None），也可带表达式（如 x = yield y），后者才能接收 send() 的值
throw() 常用于清理资源，比如在生成器中打开文件，外部可主动调用 gen.throw(GeneratorExit) 触发 finally 块

生成器嵌套时，`yield from` 真的只是语法糖？

不是。它实现了委托协议：yield from subgen 会接管 subgen 的所有 send()、throw()、close() 调用，并将子生成器的 StopIteration.value 自动作为当前 yield from 表达式的返回值——这是手动循环 for x in subgen: yield x 完全做不到的。

子生成器若抛出未捕获异常，会直接透传给父生成器，无需额外 try/except
yield from 后的表达式必须是可迭代对象或生成器，否则报 TypeError: TypeError: 'int' object is not iterable
若子生成器通过 return value 结束，该 value 成为 yield from 表达式的返回值，可在父生成器中用 result = yield from subgen 捕获

def reader():
    while True:
        data = yield
        if data == 'EOF': break
        yield f"read: {data}"
def processor():
yield from reader()  # 接管全部控制流
yield "done"
p = processor()
next(p)  # 启动
print(p.send("hello"))   # → "read: hello"
print(p.send("world"))   # → "read: world"
print(p.send("EOF"))     # → "done"

生成器耗尽后再次调用 `next()` 为什么会报 `StopIteration`？

这不是错误，是协议约定：生成器迭代协议要求迭代器在无更多值时抛出 StopIteration，for 循环、list() 构造等都依赖这个信号终止。手动捕获它反而说明你没用对场景。

不要用 try/except StopIteration 来“保护”生成器调用，应改用 for 循环或 itertools.islice() 等更安全的消费方式
生成器对象不可重用：一旦抛出 StopIteration，它永远处于耗尽状态，再次调用 next() 仍抛相同异常
若需多次遍历，要么重新调用生成器函数创建新对象，要么改用列表等可重复迭代的结构——但注意内存代价

真正卡住人的从来不是 yield 写法，而是搞不清「谁在控制执行权」和「状态保存在哪」。调试时多打印 gen.gi_frame.f_lasti（字节码偏移）和 gen.gi_running，比读文档更快定位挂起位置。