GeneratorExit是解释器向生成器主动发送的特殊退出信号，不可捕获，必须用finally块清理资源且不能含yield；显式close()确保及时释放，GC时机不确定，关键资源不可依赖。
GeneratorExit不是普通异常，不能被except捕获
GeneratorExit 是 Python 解释器在生成器被提前关闭（比如调用 close()、垃圾回收、或 break 出 for 循环）时，**主动抛给生成器内部 yield 点的特殊信号**。它继承自 BaseException 而非 Exception，所以写 except Exception: 或 except ValueError: 都拦不住它。
更关键的是：你**不该也不需要 try-except GeneratorExit**。它的设计意图就是让生成器“安静退出”，且一旦触发，生成器状态立刻变为 exhausted，再 yield 会引发 RuntimeError: generator ignored GeneratorExit。
必须用 finally 块做资源清理，且 yield 必须在 finally 外
所有需要释放的资源（文件句柄、网络连接、锁、临时文件等）都得放在 finally 块里——这是唯一可靠、被保证执行的时机。但注意：yield 语句本身不能出现在 finally 中，否则会破坏退出流程，导致解释器报错或资源未释放。
常见错误写法：
立即学习“Python免费学习笔记（深入）”；
def bad_gen():
f = open("data.txt")
try:
yield "data"
finally:
f.close() # ✅ 正确
yield "done" # ❌ 运行时报 RuntimeError正确结构是：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 把
yield放在try或函数主体中 - 把清理逻辑全塞进
finally，且不包含任何yield - 如果需在退出前返回一个值，只能靠
return（但 return 后不能再 yield）
close() 和垃圾回收都会触发 finally，但行为略有差异
手动调用 g.close() 会立即向生成器当前暂停点发送 GeneratorExit，触发 finally；而对象被 GC 回收时，也会触发，但时机不确定（尤其在 CPython 中依赖引用计数，PyPy/其他实现可能延迟）。
这意味着：
- 别依赖 GC 来释放关键资源（如数据库连接），务必显式
close() - 若生成器被用于 with 语句，可封装成上下文管理器，确保 close 被调用
- 某些场景下（如协程中被
asyncio取消），还需额外处理CancelledError，它和GeneratorExit无关，但可能同时存在
真实场景示例：安全读取大文件并自动关文件
下面是一个典型安全模式：打开文件 → 逐行 yield → 无论中断还是自然结束，finally 都保证 close() 执行：
def read_lines_safely(filename):
f = None
try:
f = open(filename, "r", encoding="utf-8")
for line in f:
yield line.rstrip("\n")
finally:
if f is not None and not f.closed:
f.close()这个写法能扛住：for line in read_lines_safely("x.txt"): break、next(g) 后不继续、或生成器变量被重新赋值覆盖 —— 全部触发 finally。
容易忽略的一点：f.close() 本身可能抛异常（比如磁盘 I/O 错误），如果想彻底健壮，得在 finally 内再套一层 try/except OSError，但通常日志记录即可，不必中断退出流程。
