根本原因是yield前异常导致清理逻辑不执行；正确做法是用try/finally包裹全部资源操作，yield仅交出资源，且需防御性判断避免覆盖原始异常。
为什么直接用 @contextmanager 容易导致资源泄漏
根本原因在于：被装饰的函数一旦在 yield 前抛出异常，yield 后的清理逻辑就永远不会执行。比如打开文件后、yield 前发生 ValueError，close() 就被跳过了。
正确做法是把所有前置准备和后置清理都包进 try/finally —— yield 只负责交出资源对象：
from contextlib import contextmanager <p>@contextmanager def open_file(path): f = None try: f = open(path, 'r') yield f # ← 这里才交出资源 finally: if f is not None and not f.closed: f.close()
- 不要在
yield前做耗时或可能失败的操作（如网络请求），否则清理不可控 - 如果必须提前校验，应在装饰器外完成，或改用自定义类实现
__enter__/__exit__ -
yield只能出现一次，且不能带值（即不能yield x后再yield y）
如何用 @contextmanager 管理多个关联资源
常见场景是数据库连接 + 游标、锁 + 临界区、临时目录 + 文件写入。关键原则是：所有资源的创建和释放必须在同一 try/finally 块中串行管理，避免部分资源未释放。
例如同时管理锁和临时文件：
立即学习“Python免费学习笔记（深入）”；
@contextmanager
def locked_tempfile(lock, path):
tmp_f = None
lock.acquire()
try:
tmp_f = open(path, 'w')
yield tmp_f
finally:
if tmp_f is not None:
tmp_f.close()
lock.release() # ← 必须确保 lock 一定释放，哪怕 open 失败
- 锁必须在
open前获取，否则open失败会导致锁未释放 - 如果资源之间有依赖（如游标依赖连接），释放顺序必须严格逆序（先关游标，再关连接）
- 不推荐在同一个
@contextmanager中混合不同生命周期的资源（如一个长连接 + 若干短时文件），应拆分为嵌套上下文
@contextmanager 和手动写 __enter__/__exit__ 的取舍
简单单资源、逻辑线性、无状态的场景，@contextmanager 更轻量；但只要涉及以下任一情况，就该退回到类实现：
- 需要保存状态（如重试次数、已分配内存地址）—— 函数作用域无法持久化
- 需支持多次进入同一上下文（如可重入锁）——
@contextmanager每次调用都新建生成器实例 - 要精细控制异常处理（比如只压制特定错误，其余继续抛出）——
__exit__的三个参数比finally更灵活 - 性能敏感路径（如高频日志写入）—— 类实例比生成器对象开销略低，且避免了
yield的协程机制
一个典型分界点：如果你发现自己在 @contextmanager 函数里开始用 nonlocal 或闭包变量存状态，就是该换类的时候了。
调试 @contextmanager 异常传播的常见盲区
最常被忽略的是：上下文退出时发生的异常会覆盖 with 块内的原始异常。例如：
with open_file('missing.txt') as f:
data = f.read() # ← FileNotFoundError
# 但实际报错可能是 finalizer 里的 AttributeError（f 已为 None）
这类问题不会立刻暴露，尤其当 finally 块里调用了可能失败的清理方法（如 shutil.rmtree、conn.rollback()）时。
- 在
finally中做清理前，务必加防御性判断（如if hasattr(obj, 'close') and callable(obj.close)） - 避免在
finally中抛出新异常；若必须，用sys.exc_info()保留原始异常链（Python 3.12+ 可用except*） - 单元测试必须覆盖“
yield前异常”和“yield后异常”两种路径，不能只测 happy path
真正难缠的从来不是写不出上下文管理器，而是没想清楚：这个资源的生命周期边界到底在哪，以及谁该为它的死亡负责。
