yield from 在父生成器关闭时自动向子生成器抛 GeneratorExit 并等待其退出；子生成器必须立即退出（捕获后需 return 或 raise），清理逻辑应放在 finally 块中确保可靠执行。
yield from 遇到 GeneratorExit 时会自动关闭子生成器
yield from 不是简单地转发 next() 或 send()，它在父生成器被关闭（例如被 close() 调用或被垃圾回收触发）时，会主动向子生成器抛入 GeneratorExit 异常，并等待其退出。这是语言层面的强制行为，无法绕过。
关键点在于：子生成器必须在接收到 GeneratorExit 后**立即退出**（不能捕获后继续 yield），否则会触发 RuntimeError: generator ignored GeneratorExit。
- 子生成器中若用
try/except GeneratorExit捕获，必须在except块末尾加return或显式raise - 子生成器中若用
try/finally，finally块仍会执行——这是清理资源的唯一可靠位置 -
yield from本身不会等子生成器“做完所有 yield”，只要父生成器关闭，就立刻推进子生成器到结束
常见错误：在子生成器里捕获 GeneratorExit 却没退出
下面这段代码会崩溃：
def subgen():
try:
yield 1
yield 2
except GeneratorExit:
print("caught!")
# ❌ 缺少 return —— 这会导致 RuntimeError
<p>def main():
g = main()
next(g)
g.close() # 触发 GeneratorExit → subgen 捕获但没退出 → crash
修复方式只有两种：
- 删掉
except GeneratorExit，靠finally做清理 - 保留
except，但末尾加return（或raise）
清理逻辑该放在 finally 还是 except GeneratorExit？
优先用 finally。因为 GeneratorExit 是特殊异常，它可能由多种路径触发（close()、__del__、作用域退出），而 finally 能覆盖全部场景；except GeneratorExit 只响应显式抛出，且容易漏掉 return 导致崩溃。
例如释放文件句柄、断开 socket、释放锁等，都应写在 finally 块里：
def read_lines(f):
try:
for line in f:
yield line.strip()
finally:
f.close() # ✅ 安全：无论正常结束、StopIteration、GeneratorExit 都执行
yield from 关闭子生成器的时机不可控
你无法预测 yield from 何时关闭子生成器——它可能发生在任意一次 next()、send()、throw() 或 close() 调用之后，甚至可能发生在 GC 回收父生成器对象时（无明确调用点）。这意味着：
- 不要依赖“子生成器一定会运行完所有 yield”来做状态假设
- 避免在子生成器中维护跨 yield 的可变状态（如计数器、缓存），除非你确保
finally能安全重置或持久化 - 如果子生成器需要异步清理（比如发网络请求关连接），
finally里不能做 await，需改用协程+任务管理
最易被忽略的是：子生成器的 finally 执行时，父生成器的栈帧可能已不存在，所以别在里面引用父级局部变量。
