Pythonwith语句和上下文管理器，到底帮你干了什么？7 个误用场景
先给结论：with语句的本质，是在代码块进入时自动调用__enter__、退出时自动调用__exit__，它解决的核心问题只有一个——不管中间是正常结束还是抛了异常，资源都能被正确释放。你以为它只是"打开文件更优雅的写法"，其实它是一层"保证收尾"的语法糖，等价于try...finally，但比手写finally可靠得多。
下面把__enter__/__exit__的运作机制拆开，再列 7 个真实误用场景，每个都给正确写法。
一、with等价于try...finally，但不会写错
不用with时，你要手动关资源：
f=open("data.txt","r")try:content=f.read()finally:f.close()# 异常时也必须关，忘了就文件句柄泄漏用with后，Python 在离开代码块时无条件调用__exit__，等于帮你写好了那个finally：
withopen("data.txt","r")asf:content=f.read()# 到此 f 已自动关闭，哪怕上面抛了异常关键点：__exit__在异常传播之前被调用，所以即使f.read()抛错，文件也会被关掉。这就是with比手写try...finally更安全的根因——你不可能"忘写 finally"。
二、__exit__的三个参数，决定了异常会不会被吞
自定义上下文管理器时，__exit__的签名是：
def__enter__(self):returnselfdef__exit__(self,exc_type,exc_val,exc_tb):# exc_type 非 None 表示代码块里抛了异常...返回值有讲究：
- 返回假值（
None/False/0）：异常继续向外传播，调用方会收到这个错。 - 返回真值（
True）：异常被吞掉，调用方以为一切正常。
classSwallow:def__enter__(self):returnselfdef__exit__(self,et,ev,tb):returnTrue# 危险！吞掉所有异常withSwallow():raiseValueError("出错了")print("居然走到这里")# 异常被静默吞掉三、误用 1：在__exit__里返回True吞掉异常
这是最隐蔽的 bug。你想"优雅处理"，结果把关键错误吃了：
def__exit__(self,et,ev,tb):ifetisnotNone:log.error("something failed: %s",ev)returnTrue# ⚠️ 异常没了，调用方毫不知情正确做法：除非你真的要压制特定异常，否则返回None（假值）让异常传播。需要压制也要显式判断类型：
def__exit__(self,et,ev,tb):ifetisFileNotFoundError:returnTrue# 只压制这一种returnFalse# 其他异常照常抛四、误用 2：以为with退出后还能用文件对象
withopen("data.txt")asf:data=f.read()print(f.read())# ❌ ValueError: I/O operation on closed filewith块一结束，上下文管理器已经把资源关了。变量f还在，但它是个已关闭的对象。需要后续用，就把使用逻辑放进with块里，或显式返回你需要的数据。
五、误用 3：多个with的嵌套顺序搞反
同时管理多个资源时，常见两种写法：
# 写法 A：逗号并联（同层级，Python 2.7+/3.1+ 支持）withopen("a.txt")asfa,open("b.txt")asfb:...# 写法 B：嵌套（进入顺序外→内，退出顺序内→外）withopen("a.txt")asfa:withopen("b.txt")asfb:...要小心的是：先开的资源后关。如果你依赖 A 在 B 关闭前还可用，嵌套顺序就很重要。一般建议用写法 A 保持扁平，可读性更好。
六、误用 4：contextlib.contextmanager忘了在yield后写收尾
用装饰器写管理器最省事，但收尾代码必须放在yield之后，且最好包在try...finally里：
fromcontextlibimportcontextmanager@contextmanagerdeftimer():start=time.time()try:yield# 这里是 with 块执行的位置finally:print(f"耗时{time.time()-start:.2f}s")# ✅ 收尾放 yield 后withtimer():do_something()坑点：如果yield之后的代码不在finally里，一旦with块抛异常，收尾逻辑就不执行。务必用try...finally包住yield。
七、误用 5：__enter__返回的不是你想要的那个对象
with ... as x里的x，是__enter__的返回值，不一定是管理器自己：
classDB:def__enter__(self):self.conn=connect()returnself.conn# as 拿到的是连接，不是 DB 实例def__exit__(self,*a):self.conn.close()withDB()asconn:conn.execute(...)# 这里用的是连接，不是 DB很多人误以为as拿到的是DB()实例，结果调用了不存在的方法。记住：as绑定的是__enter__的返回值。
八、一张表：手动try...finallyvswith
| 维度 | 手写try...finally | with上下文管理器 |
|---|---|---|
| 资源释放可靠性 | 依赖你记得写finally | 语言保证退出必调用__exit__ |
| 异常时释放 | 写了才释放，漏写就泄漏 | 无条件释放 |
| 可读性 | 样板代码多，嵌套深 | 扁平清晰 |
| 多资源管理 | 易漏关其中一个 | 逗号并联一次管好几个 |
| 自定义成本 | 无 | 实现__enter__/__exit__或用@contextmanager |
| 异常传播控制 | 你自己决定 | 由__exit__返回值决定 |
九、记住这三条就够用了
- 凡是涉及资源（文件、连接、锁、事务）的获取与释放，优先用
with，别手写try...finally。 - 自定义管理器时，
__exit__默认返回None让异常传播，别随意return True吞异常。 yield之后的收尾务必包在try...finally里，否则with块抛错时收尾不执行。
说到底，with帮你兜底的不是"打开"，而是"关闭"。它最值钱的地方，是在你最容易忘记收尾的异常路径上，替你把那扇门稳稳关上。
你平时用with时，有没有遇到过"明明关了文件却还是报句柄泄漏"的情况？评论区聊聊你踩过的上下文管理器坑。
