yield from 通过C层实现避免字节码开销，自动透传send/throw/close、异常传播、生命周期绑定及协程双向通信，支持递归遍历的线性控制流与资源安全释放。
因为 yield from 是 C 层实现的原生委托机制，跳过了 Python 字节码循环开销，同时自动透传 send()、throw()、close() 控制流——嵌套 for + yield 做不到这点。
yield from 在生成器委托中如何避免手动异常传播
嵌套循环里，子生成器抛出的异常（比如 StopIteration 或自定义异常）不会自动冒泡到外层生成器调用栈；你得自己 try/except 捕获再 raise，否则会静默终止或触发意外行为。
-
yield from会在子生成器结束时自动捕获StopIteration，并把其value属性设为自身表达式的返回值 - 子生成器内
throw(TypeError)会直接穿透到主生成器上下文，无需中间转发逻辑 - 若子生成器被
close()，主生成器也会同步进入关闭状态，而手动循环做不到这种生命周期绑定
yield from 处理递归目录遍历时的内存与控制流优势
写一个遍历嵌套目录的生成器时，常见错误是用 os.walk + 多层 for 套娃 yield，结果每层都维持独立的迭代器状态，容易卡住或漏项；yield from 让递归调用变成线性控制流。
- 递归调用
yield from scan_dir(subpath)时，解释器只保留一层栈帧，而非每次递归都压入新帧 - 遇到权限错误（
PermissionError）时，子生成器可选择continue或yield错误对象，主生成器照常运行，不中断整个遍历 - 路径过深导致
RecursionError？这不是yield from的问题，而是你没改用栈模拟递归——它本身不增加调用深度
yield from 和普通 for+yield 在协程通信中的关键差异
当你用 generator.send() 向生成器传值时，区别立刻暴露：嵌套循环无法把值送达最内层子生成器；yield from 则天然支持双向通道。
立即学习“Python免费学习笔记（深入）”；
- 主生成器收到
send('pause')，会直接转发给正在执行的子生成器，而不是卡在for循环头 - 子生成器可通过
return result结束，并让该result成为yield from表达式的值，供主生成器后续使用 - 若子生成器未定义
send()方法（比如是list或range），yield from会静默忽略传入值，而手动循环可能抛AttributeError
真正容易被忽略的是：一旦用了 yield from，你就不能再对子生成器做“部分消费”——它必须被完全耗尽，或显式 close()。中途丢弃一个被 yield from 接管的生成器，可能导致资源泄漏（比如打开的文件句柄没释放），这点比手动循环更隐蔽。
