生成器可通过 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")
<p>gen = resource_generator()
next(gen)  # 启动
gen.close()  # 输出：file closed

避免在 finally 中 yield 或 return

GeneratorExit 抛出时，生成器正处在暂停状态（刚从 yield 返回）。此时若在 finally 块中尝试 yield 或 return 带值，Python 会直接报 RuntimeError: generator ignored GeneratorExit。

Python Hardener

通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。

下载

• 清理逻辑只能做“收尾工作”，不能产生新产出
• 可以安全地调用 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
<p>@contextmanager
def managed_gen():
gen = resource_generator()
try:
yield gen
finally:
gen.close()  # 确保关闭</p><p>with managed_gen() as g:
next(g)