上下文管理器通过__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 失败时可能未定义，需额外判断。
立即学习“Python免费学习笔记（深入）”；
常见陷阱与注意事项
异常安全不等于“不会出错”，关键看 __exit__ 实现是否健壮：
-
__exit__内部若抛异常，会覆盖原始异常（除非显式处理），应避免在其中引发新异常，或至少用logging记录而非raise - 不要在
__exit__中静默吞掉所有异常（即盲目 returnTrue），这会掩盖真正问题 - 使用
@contextlib.contextmanager装饰器时，yield之后的代码等价于__exit__，同样受异常安全保证，但需注意生成器内部逻辑别崩溃
自定义时的关键实践
写自己的上下文管理器，应确保：
-
__enter__尽量轻量，失败时及时抛错（避免资源半初始化） -
__exit__做防御性清理：检查资源是否已创建、是否还有效（如if hasattr(self, '_file') and not self._file.closed:） - 清理操作本身尽量幂等（多次调用无副作用），比如关闭已关闭的文件句柄是安全的
标准库中 threading.Lock 的 __enter__/__exit__、tempfile.TemporaryDirectory 等都是经过充分验证的异常安全实现，可直接参考。
