生成器迭代结束后自动清理的实现方法

从现在开始，努力学习吧！本文《生成器迭代结束后自动清理的实现方法》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

使用 try/finally 是生成器中保证清理执行的唯一可靠方式，因 return 后代码不执行；手动调用 close() 可触发 GeneratorExit 并运行 finally；封装为上下文管理器或 async with 更安全。

使用 try/finally 在生成器中保证清理执行

生成器函数里不能靠 return 后的代码来清理，因为 StopIteration 抛出时控制流已跳出函数体。唯一可靠的方式是把主体逻辑包在 try 块里，把清理逻辑放在对应的 finally 中——无论迭代是正常耗尽、被 break 中断，还是被外部调用 generator.close() 终止，finally 都会运行。

常见错误是把清理写在生成器末尾（即 yield 之后），这种写法在绝大多数情况下根本不会执行。

def resource_generator():
    res = acquire_resource()
    try:
        for item in data_source:
            yield item
    finally:
        release_resource(res)  # ✅ 总会执行

手动调用 close() 触发生成器退出流程

当消费者提前终止迭代（比如 for 循环中 break，或只取前 N 项），Python 不会自动通知生成器“该收尾了”。此时需显式调用 generator.close()，它会向生成器内部抛出 GeneratorExit 异常，触发 finally 块。

• 不调用 close()：生成器对象可能悬空，资源泄漏风险高
• 调用 close() 后再迭代：会立即抛出 StopIteration
• close() 可安全重复调用，多次调用无副作用

注意：不要在 except GeneratorExit: 中捕获并吞掉它，否则 finally 可能被跳过；也不要在 finally 里再 yield，这会引发 RuntimeError。

用上下文管理器封装生成器更安全

如果生成器生命周期和资源绑定紧密，直接暴露原始生成器容易漏掉 close()。更稳妥的做法是把它包装成一个上下文管理器，用 with 语句确保退出时清理。

典型模式是定义一个类，实现 __iter__ 返回生成器，并在 __exit__ 中调用其 close()：

class ManagedGenerator:
    def __init__(self, *args):
        self.args = args
        self.gen = None
def __iter__(self):
    self.gen = my_generator(*self.args)
    return self.gen

def __exit__(self, *exc):
    if self.gen:
        self.gen.close()

这样使用者只需写 with ManagedGenerator(...) as gen: for x in gen: ...，无需操心手动关闭。

协程场景下 async with + aclose() 是等价方案

异步生成器（async def + yield）不能用普通 close()，必须用 aclose()，且需配合 async with 或显式 await gen.aclose()。

同样，finally 在异步生成器中依然生效，但里面的所有操作都得是 awaitable 的：

async def async_resource_gen():
    conn = await acquire_db_conn()
    try:
        async for row in query_stream():
            yield row
    finally:
        await conn.close()  # ✅ await 在 finally 中合法

异步生成器的清理比同步更易出错——比如忘了 await，或在 finally 里混用同步 I/O。这类细节一旦漏掉，程序可能卡死或资源长期占用。

本篇关于《生成器迭代结束后自动清理的实现方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！