如何通过实现__enter__和__exit__方法，用Python with语句高效管理资源？

本文共计810个文字，预计阅读时间需要4分钟。

直接说结论：

为什么 __exit__ 必须返回布尔值？

__exit__ 的返回值决定异常是否“吞掉”：返回 True 表示已处理异常，with 块外不再抛出；返回 None 或 False（默认）则异常继续向上冒泡。

• 常见错误：在 __exit__ 里写了 print("cleanup") 就完事，忘了加 return False 或显式 return None，结果异常被静默吞掉，调试时找不到报错源头
• 典型场景：日志文件写入失败时，你想记录错误但不阻止异常传播 → __exit__ 末尾不写 return，或明确写 return False
• 性能影响：返回 True 后，Python 不再做异常栈展开，这点在高频 I/O 场景下有微弱优势，但别为这点优化牺牲可读性

手动实现上下文管理器时，__enter__ 返回什么？

__enter__ 的返回值会绑定到 as 后的变量。它不强制是 self，可以是任意对象，包括 None（此时 as 变量为 None）。

• 容易踩的坑：写 def __enter__(self): return self 是最常见写法，但如果类本身不适合暴露给用户（比如内部封装了连接池），就该返回一个轻量代理对象
• 使用场景：数据库连接管理器中，__enter__ 返回一个 Cursor 实例，而非连接本身，避免用户误调 close()
• 参数差异：无参数；若需传参控制行为（如是否开启事务），应在初始化时传入，而非塞进 __enter__

用 @contextlib.contextmanager 装饰器替代手写协议？

能，而且更轻量。它把生成器函数自动转成上下文管理器，yield 之前是 __enter__，之后是 __exit__ 逻辑。

立即学习“Python免费学习笔记（深入）”；

• 常见错误：在 yield 后写普通 except 捕获异常，但装饰器不保证 yield 后代码一定执行 —— 若 yield 处抛异常且未被 __exit__ 处理，后续代码根本不会运行
• 正确做法：所有清理逻辑必须放在 try/finally 的 finally 块里，或者用 contextlib.closing() 包装已有对象
• 兼容性注意：Python 3.7+ 支持 yield 后接 return，但老版本会报 SyntaxError；生产环境建议统一用显式类实现，避免隐式行为

真正难的不是写对两个方法，而是判断「资源释放时机」是否和业务语义一致——比如网络连接在 __exit__ 关闭，但连接池可能要延迟回收；这类边界问题，文档不会写，只有压测时才暴露。