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—— 清理逻辑本身也需线程安全
真正可靠的清理，永远依赖显式控制流：yield 启动 + try/finally 包裹 + 主动 close，而不是等待解释器“帮忙”。
