yield from 通过 C 层直接接管子生成器状态机，避免字节码循环与多次 next() 调用开销，并透传 send/throw/return 值；但异常拦截、中间处理或短序列场景下应优先使用显式 for 循环。
因为 yield from 是 C 层实现的原生委托机制，跳过了 Python 字节码循环和多次 next() 调用开销。
为什么 yield from 不需要手动 for 循环
手动写 for item in subgen(): yield item 会触发 Python 解释器逐次调用子生成器的 __next__() 方法，每次都要进一次字节码循环、查方法表、处理异常边界。而 yield from 在 CPython 内部直接接管子生成器的迭代状态机，把控制权“焊死”在子生成器上，直到它抛出 StopIteration 才切回来。
- 子生成器每产出一个值，不经过主生成器函数体——没有额外的栈帧压入/弹出
- 异常（如
GeneratorExit、throw()抛出的）自动透传，无需你在try/except里手动转发 - 对列表、元组等可迭代对象也走同一套 C 层路径，不是“只优化生成器”
yield from 怎么处理子生成器的返回值
Python 3.3+ 中，子生成器可以用 return value 结束，并把 value 作为 yield from 表达式的返回值。这个值不会被产出，但能被主生成器捕获：
def sub():
yield 1
yield 2
return "done"
<p>def main():
result = yield from sub()
yield f"sub returned: {result}"</p><p>list(main()) # ['1', '2', 'sub returned: done']立即学习“Python免费学习笔记（深入）”；
- 如果子生成器没
return，yield from表达式结果是None - 手动循环无法拿到这个返回值，只能靠额外变量或约定信号值模拟
- 协程中
send()和throw()也会穿透到子生成器，手动循环必须自己try/except+sub_gen.throw(...)
哪些情况反而不该用 yield from
它不是万能加速器，滥用会掩盖逻辑或引入隐式行为：
- 子生成器可能抛出你没预料到的异常（比如
OSError），而yield from会原样透传，不像for循环那样容易插except拦截 - 需要在每个子项产出前加日志、计数、条件过滤时，显式
for更直白，yield from得包一层中间生成器 - 子生成器本身是短序列（比如就 3 个元素），性能差异可忽略，此时可读性优先
- 目标环境是旧版 Python（yield from 直接语法错误
真正关键的是：子生成器是否承担了状态管理或控制流交互（比如递归目录遍历、异步 I/O 协程链）。这时候 yield from 不只是快，而是唯一能正确传递 close()、throw() 的方式——漏掉这点，资源泄漏或静默失败比慢更致命。
