generatorexit不能用try-except捕获，它继承自baseexception而非exception；资源清理必须放在finally块中，且finally内不可yield。
GeneratorExit不是普通异常，不能用try-except捕获
GeneratorExit 是 Python 生成器被显式关闭（gen.close()）或隐式结束（如 for 循环正常退出、垃圾回收）时由解释器抛出的特殊异常，它继承自 BaseException 而非 Exception。这意味着：
-
except Exception:或except:（空 except）都捕获不到它 - 强行捕获
GeneratorExit并吞掉它，会导致生成器无法真正关闭，可能引发RuntimeError: generator ignored GeneratorExit - 你**不应该**在生成器内部用
try...except GeneratorExit去“处理”它
资源清理必须放在 finally 块中
生成器的正确清理姿势是：把释放文件句柄、关闭连接、解锁等逻辑统一放进 finally 子句。Python 保证只要生成器执行到 yield 后暂停过，无论因 close()、throw()、正常耗尽还是被 GC 回收，finally 都会执行。
示例：
def file_reader(path):
f = open(path, 'r')
try:
for line in f:
yield line.strip()
finally:
print(f"Closing {path}") # 这里一定会执行
f.close() # 即使调用 gen.close() 也会走到这里
注意：finally 中不要有 yield，否则会触发 RuntimeError: generator raised StopIteration（Python 3.7+）或更早版本的未定义行为。
close() 调用后不能再 yield，也不能再调用 next()
一旦外部调用 gen.close()，生成器状态立即变为 GEN_CLOSED，后续任何操作都会失败：
- 再次调用
gen.close()→ 无反应（安全，可重复调用） - 调用
next(gen)或gen.send(...)→ 抛出StopIteration（Python 3.7+）或RuntimeError: generator already executing（旧版） - 在
finally里 yield → 直接报错，如上所述
所以清理逻辑只做“收尾”，不做“产出”。
需要手动 close 的典型场景和陷阱
大多数时候你不需要显式调用 close() —— for 循环、list(gen)、sum(gen) 等都会自动调用。但以下情况必须主动 close：
- 生成器持有长期资源（如数据库连接、socket、子进程），且你提前中断迭代（比如 break 出 for 循环）
- 生成器作为上下文管理器的一部分，但没用
with包裹 - 生成器被多处引用，你无法确定谁会最后消费它
常见错误：
- 在
except块里忘了gen.close()，导致资源泄漏 - 误以为
del gen就等于关闭 —— 实际上只是减少引用计数，GC 时间不确定 - 在异步生成器（
async def+yield）中混用同步close()—— 应该用agen.aclose()
最易被忽略的一点：finally 块里的代码可能抛出新异常，这会掩盖原本的 GeneratorExit；如果清理逻辑本身不可靠（比如网络超时、磁盘满），最好加一层 try/except 包住清理语句，避免中断关闭流程。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
