生成器可通过 close() 主动关闭并触发 finally 清理，但需含 try...finally 或 with；close() 同步立即生效，不可在 finally 中 yield；关键资源须显式关闭或用 with 管理。
生成器可以通过 close() 方法在外部被主动关闭，从而触发其内部的清理逻辑（如 finally 块或 __del__ 中的资源释放），但前提是生成器函数中包含可被中断并执行的清理结构。
使用 close() 触发 GeneratorExit 和 finally
调用生成器对象的 close() 方法会向其协程栈抛出 GeneratorExit 异常，该异常不能被常规 except 捕获（否则会报 RuntimeError），但会确保 finally 块被执行——这是最常用、最可靠的清理入口。
- 生成器函数中必须有
try...finally或with语句才能保证清理代码运行 -
close()是同步操作，立即生效，不等待当前yield完成 - 若生成器已结束（耗尽或已被关闭），再次调用
close()无效果
def resource_generator():
f = open("temp.txt", "w")
try:
yield "writing..."
yield "done"
finally:
f.close() # close() 调用后这里一定会执行
print("file closed")
gen = resource_generator()
next(gen) # 启动
gen.close() # 输出：file closed
避免在 finally 中 yield 或 return
GeneratorExit 抛出时，生成器正处在暂停状态（刚从 yield 返回）。此时若在 finally 块中尝试 yield 或 return 带值，Python 会直接报 RuntimeError: generator ignored GeneratorExit。
- 清理逻辑只能做“收尾工作”，不能产生新产出
- 可以安全地调用
close()、shutdown()、cancel()等无返回副作用方法 - 若需异步清理，应改用异步生成器（
async def+aclose()）
注意 __del__ 不可靠，不应用于关键清理
虽然生成器对象销毁时可能触发 __del__，但它受垃圾回收时机影响，无法保证何时执行，甚至可能永不执行（尤其存在循环引用时）。
-
__del__不是close()的替代方案 - 关键资源（如文件、网络连接、锁）必须显式
close()或用with管理 - 可将
__del__仅作为防御性兜底（例如打日志提示“未显式关闭”）
配合上下文管理器自动关闭
为防忘记调用 close()，可将生成器封装为上下文管理器，利用 with 语句保障退出时自动清理。
- 通过继承
contextlib.AbstractContextManager或实现__enter__/__exit__ - 更轻量的方式是用
contextlib.contextmanager装饰普通函数 -
with块退出（无论正常或异常）都会调用__exit__，其中可安全调用gen.close()
from contextlib import contextmanager@contextmanager def managed_gen(): gen = resource_generator() try: yield gen finally: gen.close() # 确保关闭
with managed_gen() as g: next(g)
