Python 上下文管理器如何保证异常安全？

上下文管理器通过__enter__和__exit__协议强制执行资源清理，无论正常退出或异常均调用__exit__，确保异常安全；其比手动try/finally更可靠、职责清晰且复用性强。

Python 上下文管理器通过 __enter__ 和 __exit__ 协议，在代码块退出（无论正常结束还是抛出异常）时，**强制执行资源清理逻辑**，

从而保证异常安全。

核心机制：__exit__ 总是被调用

with 语句在离开代码块时，不管是否发生异常、异常是否被处理、是否提前 return 或 break，都会调用上下文管理器的 __exit__(exc_type, exc_value, traceback) 方法。这是由 Python 解释器底层保障的，不依赖于用户代码的控制流。

• 如果没异常：exc_type 为 None，__exit__ 仍会运行，适合做常规清理（如关闭文件、释放锁）
• 如果发生异常：exc_type、exc_value、traceback 为对应信息，__exit__ 可选择“吞掉”异常（返回 True）或让其继续传播（返回 False 或 None）

与手动 try/finally 对比更可靠

手动写 try...finally 理论上也能做到异常安全，但容易遗漏或出错：

• 忘记写 finally，或把清理逻辑错放在 try 或 except 中
• 多层嵌套时，缩进和逻辑易混乱
• 上下文管理器把“获取资源”和“释放资源”的绑定封装在同一个对象里，职责清晰、复用性强

例如打开文件：with open('data.txt') as f: —— 即使 f.read() 抛 UnicodeDecodeError，文件也一定被关闭；而手写 open + finally: f.close() 虽可行，但每次都要重复、且 f 在 open 失败时可能未定义，需额外判断。

常见陷阱与注意事项

异常安全不等于“不会出错”，关键看 __exit__ 实现是否健壮：

• __exit__ 内部若抛异常，会覆盖原始异常（除非显式处理），应避免在其中引发新异常，或至少用 logging 记录而非 raise
• 不要在 __exit__ 中静默吞掉所有异常（即盲目 return True），这会掩盖真正问题
• 使用 @contextlib.contextmanager 装饰器时，yield 之后的代码等价于 __exit__，同样受异常安全保证，但需注意生成器内部逻辑别崩溃

自定义时的关键实践

写自己的上下文管理器，应确保：

• __enter__ 尽量轻量，失败时及时抛错（避免资源半初始化）
• __exit__ 做防御性清理：检查资源是否已创建、是否还有效（如 if hasattr(self, '_file') and not self._file.closed:）
• 清理操作本身尽量幂等（多次调用无副作用），比如关闭已关闭的文件句柄是安全的

标准库中 threading.Lock 的 __enter__/__exit__、tempfile.TemporaryDirectory 等都是经过充分验证的异常安全实现，可直接参考。