如何让生成器在 close() 时执行清理逻辑（del 替代）_技术教程

generator.close() 触发清理的唯一可靠方式是配合 yield 和 try/finally：清理代码必须放在 yield 后的 finally 块中，且生成器需已启动（调过 next()），否则 close() 不执行 finally。

generator.close() 触发清理的唯一可靠方式是配合 yield

Python 的 generator.close() 不会自动执行任意清理代码，它只向生成器抛出 GeneratorExit 异常，并要求生成器在收到该异常后**立即退出**（不能捕获、不能 yield、不能 return 值）。所以，想让清理逻辑运行，必须把清理代码放在 try/finally 的 finally 块里，且该块必须在 yield 之后、生成器函数自然结束前被覆盖到。

错误写法：finally 放在 yield 外层但函数已无后续执行路径（比如 yield 后直接 return），close() 时 finally 可能不执行
正确结构：必须有 yield → 暂停 → 等待下次 next() 或被 close() 中断 → 进入 finally
del 不等于 close()：显式 del gen 仅减少引用计数，是否触发 close() 取决于解释器（CPython 通常会，PyPy/多线程下不保证），绝不能依赖

用 try/finally + yield 实现可预测的清理

这是目前最稳定、跨 Python 版本和实现都有效的模式。关键点在于：yield 必须出现在 try 块中，或 yield 后仍有可执行路径让 finally 被进入。

def resource_generator():
    res = acquire_resource()
    try:
        yield res
    finally:
        release_resource(res)  # close() 时必执行

如果生成器还没开始迭代（next() 都没调过），close() 不会触发 finally —— 因为还没进 try
如果生成器已耗尽（抛出 StopIteration），再调 close() 是安全的，但 finally 已执行过了
不要在 finally 里 yield 或 return 值，否则引发 RuntimeError: generator ignored GeneratorExit

为什
么 del 和 weakref.finalize 不适合替代 close()

试图用对象析构机制模拟清理，会引入不可控延迟和竞态，尤其在 CPython 以外的实现中风险更高。

__del__ 不保证何时调用（甚至可能永不调用），且禁止在其中做 I/O 或持有锁；生成器对象的 __del__ 更不可靠，因为底层 frame 可能被循环引用卡住
weakref.finalize 的回调时机完全异步，无法与业务逻辑同步；若清理涉及释放文件描述符、数据库连接等有限资源，延迟释放可能导致 Too many open files
生成器本身不是普通类实例，它的生命周期由 C 层 frame 管理，__del__ 行为更难预测

实际使用中容易忽略的边界情况

即使写了 try/finally，仍可能因调用时机或状态导致清理失效。

生成器从未被 next() 启动：此时 gen.close() 不会执行 finally，需在生成器开头加 guard 逻辑（如先 acquire 再 yield，确保 finally 总有对应入口）
生成器被 for 循环消费完：循环会自动调 close()，但仅当未提前 break；若 break，则不会自动 close()，必须手动补调
多线程环境：一个线程调 close()，另一个线程同时调 next()，可能引发 RuntimeError: generator already executing —— 清理逻辑本身也需线程安全