Python 生成器 close() 为什么不生效：GeneratorExit 与 finally 清理边界

线上批处理把一个生成器提前停掉后，临时文件没有按预期关闭，最容易误判的地方是：close() 并不是“立刻销毁对象”，它会向生成器内部注入 GeneratorExit。只要生成器已经开始运行，且没有把这个异常吞掉，finally 通常会执行；但生成器尚未启动、代码错误地捕获退出异常，或者只删除了一个引用时，结果就不同。

先复现：close() 到底在哪一刻触发清理

先用一个带状态输出的生成器，不接文件、不接网络，只观察控制流。这里故意让生成器至少产出一次，因为“创建了对象”和“生成器函数真正开始执行”是两件事。

def rows():
    print("open")
    try:
        yield "row-1"
        print("continue")
        yield "row-2"
    finally:
        print("cleanup")

stream = rows()
print(next(stream))
stream.close()

运行结果应先看到 open、row-1，然后看到 cleanup。continue 不会出现，因为 close() 让暂停点直接进入退出路径，而不是继续取下一行。

问题现场：为什么有时调用 close() 却看不到 finally

最常见的现场是生成器刚创建就被关闭：

stream = rows()
stream.close()

这段代码不会打印 open，也不会打印 cleanup。生成器函数体尚未执行，函数里的 try 还没有建立，自然没有已进入的清理路径。若资源是在第一次 next() 之后才打开，这个行为是合理的。

另一个误区是把 del stream 当成确定的释放动作。引用计数实现下，析构可能很快发生；循环引用、不同 Python 实现或仍有其他引用时，时间就不再确定。需要确定时机，就显式调用 close()，并让生成器内部拥有资源的生命周期。

动手验证：GeneratorExit 的边界怎么判断

可以在清理分支里记录退出原因，但不要把它改写成普通业务异常：

def stream_rows():
    try:
        yield "row-1"
        yield "row-2"
    except GeneratorExit:
        print("generator is closing")
        raise
    finally:
        print("release resource")

这里的 raise 很重要。GeneratorExit 表示调用方要求生成器结束，捕获后继续向外抛出，才能保留协议语义。更简单、更稳妥的写法通常是不单独捕获它，只保留 finally 做释放。

定位根因：清理代码里哪些写法会让程序出错

生成器在关闭期间不能再次产出值。下面的写法会触发运行时错误：

def broken_rows():
    try:
        yield "row-1"
    finally:
        yield "closing-row"

调用 next() 后再调用 close()，Python 会报告生成器在退出时产生了值。清理阶段只做关闭文件、归还连接、删除临时状态等副作用，不要把“最后一条数据”设计成 yield。

同样不要写成 except BaseException: pass。它可能把 GeneratorExit、用户主动取消和真正的系统级退出混在一起，最后看起来像“关闭成功”，实际资源状态却没有核对。

修复方案：把资源和生成器绑定起来

如果生成器自己打开文件，最小可靠结构是把打开动作和读取循环放进同一个 try/finally。业务侧停止消费时调用 close()，由生成器负责关闭文件：

def read_lines(path):
    handle = open(path, encoding="utf-8")
    try:
        for line in handle:
            yield line.rstrip("\n")
    finally:
        handle.close()

若调用方同时持有文件句柄，就应该改用 with open(...)，并明确由哪一层负责生命周期。不要让一半资源由生成器管理，另一半由外部对象猜测。

验证结果：用三组测试锁住回归边界

回归测试至少覆盖“已启动后关闭、自然耗尽、从未启动”三组情况。测试不要只断言返回值，还要断言清理标志：

def test_close_runs_cleanup():
    state = []

    def values():
        try:
            yield 1
        finally:
            state.append("closed")

    item = values()
    next(item)
    item.close()
    assert state == ["closed"]

自然耗尽时，下一次取值抛出 StopIteration，finally 也应执行；未启动的生成器则不应假设函数体内的初始化和清理已经发生。这三个断言能把最容易被重构破坏的边界固定下来。

相关问题

生成器自然遍历结束后还需要 close() 吗？

通常不需要重复调用。自然结束会走 finally；显式 close() 主要用于提前停止消费的场景。

可以在 finally 里捕获异常并返回默认值吗？

可以处理普通清理异常，但要谨慎区分业务异常和退出协议。不要吞掉 GeneratorExit，也不要在关闭阶段再次 yield。

生成器适合长期持有数据库连接吗？

只有当连接的生命周期和生成器明确绑定、并且所有提前退出路径都经过 finally 时才适合。复杂事务更建议使用显式上下文管理器。

小结

排查生成器清理问题时，先问两个问题：生成器是否真正启动过，暂停点是否能通过 close() 进入 finally。再检查清理分支有没有 yield、是否吞掉 GeneratorExit，以及资源是否被多层对象共同持有。把这些边界写进测试，生成器的提前停止就不再依赖偶然的析构时机。