yield from 主要解决生成器委托的代码冗余和控制流复杂性问题，并非性能优化手段；它本质是语法糖，逐个yield、不跳过迭代、不减少协程切换开销。
yield from 不是性能优化的银弹，它主要解决的是生成器委托的代码冗余和控制流复杂性问题；真要提升执行效率，得看具体场景——多数时候它反而比手动循环略慢一点。
yield from 本质是语法糖，不是加速器
它把 for item in subgen: yield item 这种模式压缩成一行，背后仍是逐个 yield，不跳过迭代、不合并状态、不绕过 Python 的生成器调度开销。
- CPython 中，
yield from实际调用子生成器的__next__()方法，和手动循环一样走完整协程切换路径 - 如果子生成器本身返回大量小对象（比如逐字符 yield），
yield from和手动 for 循环的耗时差异通常在 5% 以内，可忽略 - 但若子生成器含复杂初始化逻辑（如打开文件、建连接），
yield from不会提前触发——它仍遵循“首次 next 才启动子生成器”的惰性原则
真正能省开销的场景：避免中间生成器对象堆积
嵌套多层生成器时，手动 yield 每一层容易写出“中转生成器”，导致额外对象创建和栈帧累积；yield from 可扁平化委托链。
# ❌ 容易写成这样：每层都 new 一个 generator 对象
def gen_a():
yield from [1, 2]
def gen_b():
yield from gen_a() # ← 这里已创建 gen_a 实例
def gen_c():
yield from gen_b() # ← 再创建 gen_b 实例
<h1>✅ 更直接的委托（效果等价，但更清晰）</h1><p>def gen_c_v2():
yield from [1, 2] # 直接 yield from 可迭代对象，跳过中间层
- 当子生成器是简单可迭代对象（
list、range、str），yield from底层走 C 优化路径，比 Python 层 for 循环略快 - 但如果子生成器是自定义类且实现了
__iter__+__next__，yield from和手动循环性能基本一致 - 注意：不要为了“看起来扁平”而强行用
yield from委托非生成器——比如对普通函数调用，会直接报TypeError: 'int' object is not iterable
容易踩的坑：异常传播与 close 行为不直观
yield from 会接管子生成器的异常处理和关闭流程，这点常被忽略，导致资源泄漏或静默失败。
立即学习“Python免费学习笔记（深入）”；
- 向使用
yield from的生成器发送generator.throw()，异常会先传给子生成器；若子生成器没捕获，才冒泡到外层 -
generator.close()会先调用子生成器的close()——但如果子生成器已结束，不会报错；而手动 for 循环中你得自己确保close()子生成器 - 最典型陷阱：
yield from后跟的表达式如果抛出StopIteration（比如空生成器），会被吞掉，外层不会终止——这和手动 for 循环行为一致，但初学者常误以为“该停了”
真正影响效率的，往往是生成器里干了什么，而不是怎么 yield。别迷信 yield from 能提速，先确认瓶颈在迭代本身，还是在数据构造、IO 或计算上。
