Python的with语句依赖__enter__和__exit__方法实现上下文管理：前者在进入时获取资源并返回对象，后者在退出时无论是否异常都执行清理，且可通过返回True抑制异常。
用 __enter__ 和 __exit__ 手动实现上下文管理器
Python 的 with 语句背后依赖两个特殊方法：__enter__ 返回进入上下文时的资源（比如打开的文件、数据库连接），__exit__ 负责清理（关闭、回滚、释放锁等）。只要类实现了这两个方法，就能被 with 使用。
常见错误是忽略 __exit__ 的三个参数：exc_type、exc_value、traceback。它们用于判断是否发生了异常——如果都为 None，说明没出错；否则需决定是否吞掉异常（返回 True）或让其继续传播（默认返回 None 或 False）。
实操建议：
-
__enter__应尽量轻量，避免在其中做耗时或可能失败的操作（比如网络请求），否则with块还没开始就崩溃，__exit__根本不会调用 -
__exit__必须能处理资源未成功初始化的情况（例如__enter__抛了异常，导致实例属性未设置），否则清理时会触发AttributeError - 若资源是外部对象（如传入的文件描述符），不要在
__exit__中无条件调用.close()，先检查是否已关闭或是否为有效句柄
用 @contextlib.contextmanager 装饰器简化实现
手动写双方法样板代码繁琐，尤其当逻辑集中在“中间执行块”时。@contextlib.contextmanager 允许你用生成器函数定义上下文：yield 之前的部分相当于 __enter__，之后（finally 块中）相当于 __exit__。
立即学习“Python免费学习笔记（深入）”；
关键点在于：必须用 try/finally 包裹 yield，否则异常发生时清理逻辑不会执行。装饰器本身不捕获异常，只是把生成器暂停/恢复机制桥接到上下文协议。
实操建议：
- 不要在
yield后面写普通语句（即yield必须是函数最后一条可执行语句），否则会触发RuntimeError: generator didn't stop - 若需向
with语句暴露资源，用yield resource；若无需暴露，直接yield即可 - 所有清理代码必须放在
finally块里，不能放在except后的普通代码路径中——因为__exit__总是会被调用，无论是否异常
资源未释放的典型场景和排查方式
最常被忽略的是：上下文管理器本身抛异常时，__exit__ 仍会被调用，但此时资源可能根本没创建成功。例如打开文件失败，self.file 属性不存在，而 __exit__ 还试图调用 self.file.close()，结果引发二次异常掩盖原始错误。
另一个隐蔽问题是嵌套上下文中的异常压制：如果外层 __exit__ 返回 True，内层异常会被吞掉，调试时看不到真实报错位置。
排查建议：
- 在
__exit__开头加守卫判断：if not hasattr(self, 'resource'):→ 直接return - 用
logging.debug在__enter__和__exit__中打点，确认两者是否成对出现（特别关注程序提前退出、信号中断、sys.exit()等场景） - 对关键资源（如数据库连接、线程锁），在
__exit__清理后主动验证状态（如检查conn.closed、lock.locked()）并记录不一致情况
与 contextlib.closing 和 contextlib.nullcontext 的配合使用
不是所有资源都自带上下文支持。比如某些老库返回的对象只有 .close() 方法但没实现上下文协议，这时可以直接套一层 contextlib.closing(obj) ——它内部就是个通用的 __exit__ 调用器。
而 nullcontext 是 Python 3.7+ 提供的“空上下文”，适用于需要统一写 with 语法但某些分支无需资源管理的场景（比如开关控制是否启用某资源）。它不做任何事，yield 后立即结束。
注意点：
-
closing不检查obj是否真有close方法，运行时报AttributeError；建议先hasattr(obj, 'close')防御 -
nullcontext的yield值是None，如果业务逻辑依赖with x as y:中的y，得显式传参：nullcontext(some_value) - 别为了“看起来整齐”强行把简单资源包装成上下文——比如单次字符串处理不需要
with nullcontext()
真正难的不是写出能跑的上下文管理器，而是预判资源生命周期边界在哪：谁创建、谁销毁、异常时谁负责兜底、并发时是否可重入。这些细节藏在业务逻辑里，而不是语法里。
