直接用 try/finally 不够，因其逻辑分散易遗漏；而 enter 和 exit 通过上下文管理协议确保无论正常或异常退出都执行清理。
为什么直接用 try/finally 还不够？
手动写 try/finally 确实能释放资源，但逻辑分散、重复多，尤其在嵌套或多个资源共存时容易漏掉某一层的 close()。而 __enter__ 和 __exit__ 是 Python 上下文管理协议的核心，让 with 语句能自动触发初始化和清理——关键在于它不依赖代码执行路径：即使中间抛异常、return 或 break，__exit__ 都会被调用。
怎么写一个最简可用的上下文管理器？
只需定义两个方法：__enter__ 返回要绑定的值（比如文件对象），__exit__ 处理清理并决定是否压制异常。注意：__exit__ 必须接收三个参数：exc_type、exc_value、traceback，哪怕你什么都不做也得写全。
示例：一个模拟数据库连接的类
class DBConnection:
def __init__(self, host):
self.host = host
self._conn = None
<pre class="brush:php;toolbar:false;">def __enter__(self):
self._conn = f"conn_to_{self.host}"
return self._conn # 绑定给 as 后的变量
def __exit__(self, exc_type, exc_value, traceback):
if self._conn:
print(f"Closing {self._conn}")
# 返回 False 表示不压制异常；返回 True 才会吞掉异常
return False
使用时：
with DBConnection("localhost") as conn:
print(conn)
raise ValueError("oops")
# 仍会打印 "Closing conn_to_localhost"，且异常照常抛出
常见错误：__exit__ 返回值搞反了
这是最容易踩的坑——误以为返回 True 是“成功关闭”，结果把本该暴露的异常给吞了，调试时完全看不到报错源头。
-
__exit__返回True：异常被抑制，with块外无法捕获 -
__exit__返回False或None（默认）：异常继续向上抛 - 只在明确需要拦截特定异常时才返回
True，比如日志记录后静默忽略ConnectionError
更安全的做法是：在 __exit__ 里只做清理，不碰返回值，除非真有压制逻辑。
不想写类？用 contextlib.contextmanager 更轻量
如果只是简单封装已有函数（比如打开文件、加锁、临时修改配置），用装饰器比写完整类更直接。生成器函数里 yield 之前的逻辑相当于 __enter__，之后的相当于 __exit__（支持 except 捕获异常）。
from contextlib import contextmanager <p>@contextmanager def temporary_env(key, value): old = os.environ.get(key) os.environ[key] = value try: yield finally: if old is None: os.environ.pop(key, None) else: os.environ[key] = old </p>
用法一样：
with temporary_env("DEBUG", "1"):
print(os.environ["DEBUG"]) # 1
# 出 with 后自动恢复原 env
注意：@contextmanager 要求函数必须有 yield，且清理逻辑务必放在 finally 或 except 中，否则异常时资源不会释放。
真正难的不是写对这两个方法，而是想清楚哪些状态变更需要配对回滚——比如修改了全局变量、改了线程局部存储、拿了系统信号句柄……这些都得在 __exit__ 里显式还原，否则一次异常就可能污染后续所有执行。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
