1. 从一次无意中的资源泄露说起：为什么你会需要with语句

先讲个我早年的经历。那会儿刚开始写Python，接手的第一个活儿是写一个日志清洗脚本，处理完几万个文件后，系统一直报"打开的文件过多"。排查了半天，最后发现问题是某个函数里打开文件后忘了close。文件对象被局部变量引用，函数返回后那个对象应该被回收才对，但垃圾回收器也不是随时都在干活，文件描述符这种资源不会立刻释放。几万次循环叠加下来，文件描述符全被占满了。

当时团队里的老哥丢过来一句话："用with open啊。"我照着改了，问题确实消失了，但说实话，那会儿我只知道with能自动关文件，完全不知道它为什么能关、靠什么机制关。后来踩坑多了才慢慢明白，如果只把with当成"自动关文件"的语法糖，你会错过它真正厉害的地方，也会在不少地方栽跟头。

这篇文章就把with语句从头到尾拆开来讲：底层协议、四个高频场景、多资源管理、contextlib工具，以及老手也会踩的几个坑。不管你是刚入门的新手，还是已经写过一阵子Python的开发者，都能从中找到点有用的东西。

先建立第一个正确的认知：with语句不是一个"文件专用关键字"，它背后是一套通用的协议，叫上下文管理协议（Context Management Protocol）。任何遵守了这套协议的对象，都可以用with来管理。文件只是最常见的例子之一。

2. 上下文管理器的底层契约：__enter__和__exit__到底在干什么

要理解with，必须先理解两个魔法方法：__enter__和__exit__。Python官方文档里把实现了这两个方法的对象叫做"上下文管理器（Context Manager）"。

2.1 一次with的执行过程，拆成三步看

当你写这样一段代码：

with open("test.txt", "r") as f: data = f.read()

Python解释器实际执行了三件事：

1. 调用open("test.txt", "r")拿到文件对象，然后调用这个对象的__enter__()方法。
2. 把__enter__()的返回值赋给as后面的变量f。
3. 执行缩进块里的代码。无论代码是正常执行完、还是抛了异常、还是执行了return，在离开缩进块时都会调用__exit__()方法。

关键点在于第2步：as f拿到的不是open()返回的那个对象本身，而是它的__enter__()方法的返回值。文件对象的__enter__()返回的是它自己，所以f看起来就像"原文件对象"。但这不是协议强制要求的，你完全可以让__enter__()返回别的值。这一点后面讲自定义管理器时会更清楚。

__exit__方法接收三个参数，分别对应异常类型、异常值和traceback对象：

def __exit__(self, exc_type, exc_value, traceback): ...

如果with块内没有异常，这三个参数都是None。记住这个签名，后面讲异常处理坑的时候会用到。

2.2 用类实现自己的上下文管理器：一个计时器

理解协议最好的方式是自己写一个。我来写一个简单的代码块计时器：

import time class Timer: def __enter__(self): self.start = time.perf_counter() return self def __exit__(self, exc_type, exc_value, traceback): self.elapsed = time.perf_counter() - self.start print(f"代码块耗时: {self.elapsed:.4f} 秒") # 返回 None，相当于返回 False，不吞异常

用法：

with Timer() as t: time.sleep(0.3) # 输出: 代码块耗时: 0.3001 秒

这个例子里，__enter__返回self，所以t就是Timer实例，退出时可以访问t.elapsed。这个设计模式在需要"记录一段代码快照状态"的场景里非常常见。

再看一个更贴近实际用法的例子：临时切换当前工作目录。以前我经常写脚本时要临时进某个子目录处理完再退出来，手动os.chdir切来切去特别容易忘，一旦中间抛异常，目录就留在错误状态了。用上下文管理器就能优雅解决：

import os from pathlib import Path class cd: def __init__(self, path): self.new_path = Path(path).expanduser().resolve() self.old_path = None def __enter__(self): self.old_path = Path.cwd() os.chdir(self.new_path) return self.new_path def __exit__(self, exc_type, exc_value, traceback): os.chdir(self.old_path)

用起来就是这样：

with cd("/tmp/workspace"): # 处理当前目录下的文件 with open("data.txt", "w") as f: f.write("hello") # 退出with后，目录自动切回原处

这类管理器最大的价值不是帮你省几行代码，而是无论中间代码是否抛异常，退出动作都会执行。靠人肉写try...finally容易漏，靠上下文管理器是结构性的保证。

3. 文件、数据库、锁、网络会话：四个高频场景的实战写法

知道原理之后，我们看几个最常见的with应用场景。这些场景覆盖了大多数Python开发者的日常工作。

3.1 文件读写：最经典也最容易写错

最基础的是文件读写：

with open("report.txt", "w", encoding="utf-8") as f: f.write("这是内容\n")

三个容易忽略的细节：

• encoding="utf-8"一定要写。Windows上如果不指定，默认可能是gbk，代码一旦部署到Linux上，编码不一致会直接导致乱码。这是我见过的最普遍的Python中文文件读写问题。
• 读文件时写不写with差别尤其明显。不写with，文件虽然会被垃圾回收器回收，但回收时机不可控；写了with，代码块一结束，文件描述符立刻释放。
• 文件对象在真实项目里常被当成"写满再读回"的临时缓冲。比如先with open(...) as f:写入，再在另一个with open(...) as f:里读回来，两端用with包上，文件状态一定干净。

有一个反直觉的点要特别记住：文件对象在退出with之后，依然可以引用，但已经处于关闭状态。比如：

with open("test.txt", "r") as f: pass print(f.closed) # True f.read() # 抛 ValueError: I/O operation on closed file.

如果你在with块外面还想用这个f变量，必须先把内容读出来保存到普通变量里。

3.2 数据库连接与事务：一个容易产生误会的场景

数据库连接是另一个高频场景。以Python自带的sqlite3为例：

import sqlite3 conn = sqlite3.connect("example.db") with conn: conn.execute("INSERT INTO users(name) VALUES (?)", ("Alice",))

很多人以为with conn的作用是"用完自动关闭连接"，这个理解是错的。它真正做的，是开启一个事务，并在代码块结束时提交事务；如果代码块内抛了异常，则回滚事务。连接对象的__exit__并不会关闭连接，它处理的是事务边界。

这里有个我在实际排查中踩过的坑：最初我写代码没有用with conn，只写：

conn.execute("INSERT INTO users(name) VALUES (?)", ("Alice",)) conn.close()

结果数据没有写入数据库，程序也没报错。我当时很困惑，于是加了日志逐行看，确认execute确实执行了，然后又开了个终端去查数据库，发现表里空空的。最后查文档才明白：sqlite3默认情况下，execute之后需要调用conn.commit()，否则事务不会持久化，close()时未提交的事务直接回滚。

当时的修复方案就是给execute套一层with conn。如果你的业务逻辑是"这组SQL应作为一个整体，要么全部成功要么全部回滚"，就应该写with conn:。这比手动commit/rollback要可控得多。但要注意，事务的粒度是"这一整段代码"，不是单条语句。

顺带说一句：连接对象本身也支持"用完自动关闭"的写法，那是contextlib.closing干的事，它们俩经常被混用。在事务语义和自动关闭这两个需求并存时，正确的写法往往是嵌套的：

from contextlib import closing with closing(sqlite3.connect("example.db")) as conn: with conn: conn.execute("INSERT INTO users(name) VALUES (?)", ("Alice",))

外层管连接生命周期，内层管事务边界。各干各的事，互不干扰。

3.3 多线程锁：with是acquire/release的天然搭档

Python的threading.Lock对象实现了上下文管理器协议，所以with是替代手动acquire/release最干净的写法。使用方式：

import threading lock = threading.Lock() counter = 0 def increment(): global counter with lock: # 临界区：同一时刻只允许一个线程进入 counter += 1

手动写法是：

lock.acquire() try: counter += 1 finally: lock.release()

两者等价，但with明显更清爽。锁这个场景尤其需要关注异常安全：临界区里如果抛了异常，手动写法里忘了finally就会造成死锁——下一次任何线程再想获取锁都会被永久卡住。用with从结构上就杜绝了这个问题。

threading.Condition、RLock这些同步原语也都实现了同样的协议。在涉及多线程的代码里，with lock应该成为默认习惯，而不是可选项。

3.4 网络会话：requests.Session连接复用

写爬虫或者调第三方API时，频繁创建连接是性能毒药。requests库里的Session对象会复用TCP连接，但它也需要正确关闭。用with是推荐做法：

import requests with requests.Session() as session: resp = session.get("https://api.example.com/data", timeout=10) if resp.status_code == 200: data = resp.json()

Session的__exit__会调用close()，把连接池释放掉。如果你在大量循环里每次都new一个Session、又不管它，连接池堆积到一定程度就会报"Connection pool is full"或者触发文件描述符耗尽。这个场景在写爬虫时尤其常见，也是热词里大量出现"python爬虫"的现实原因——爬虫跑着跑着突然变慢，多半就是连接没管理好。

把四个场景放到一张表里对照，你会更清楚with在不同对象的语义差异：

4. 一口气管理多个资源：嵌套写法与逗号分隔的边界

项目里经常遇到需要同时打开两个文件的情况，比如把一个文件的内容处理之后写到另一个文件。新手常见的写法：

with open("a.txt", "r") as f1: with open("b.txt", "w") as f2: f2.write(f1.read())

两层嵌套功能上是没问题的，就是从缩进上看有点啰嗦。好在Python支持多个上下文管理器写在同一个with语句里，用逗号隔开：

with open("a.txt", "r") as f1, open("b.txt", "w") as f2: f2.write(f1.read())

这两种写法在语义上等价，都是"两个资源按从左到右的顺序进入，退出时按相反顺序退出"。但业界后来有了不同的声音。官方在Python 2.7到3.9的文档中建议"如果代码行太长，或者上下文管理器很多，应该用嵌套而不是逗号"——理由是出现异常时，嵌套写法能更清楚地看到哪个管理器是负责哪块代码。

我的个人习惯是：

• 两个平级资源、逻辑上就是并列的（比如一个读一个写），用逗号分隔写一行或两行，可读性更好。
• 资源之间有依赖关系时，无脑嵌套。比如管理锁的同时又要操作基于该锁保护的数据对象，嵌套写法才能准确表达"先加锁，再在临界区里处理资源"的顺序。
• 超过3个管理器，建议考虑拆函数，一个函数管两三个资源已经快到极限了。

还有一个语法细节需要注意。从Python 3.10开始，可以用括号把多个上下文管理器括起来：

with ( open("a.txt", "r") as f1, open("b.txt", "w") as f2, ): f2.write(f1.read())

这在3.9及以下版本会直接语法报错，如果你还在维护旧环境，别用这个写法。

5. 用@contextmanager装饰器偷懒：少写样板代码的高效路径

类是实现上下文管理器最完整的办法，但日常使用中，很多时候我们并不需要一个完整的类——只需要"进入时做点事，退出时做点事"。这时候contextlib.contextmanager装饰器是更轻的选择。

5.1 核心用法：yield切开前后两半

下面是一个例子，需求是测量代码块运行时间：

from contextlib import contextmanager import time @contextmanager def timer(label="代码块"): start = time.perf_counter() try: yield finally: elapsed = time.perf_counter() - start print(f"{label}耗时: {elapsed:.4f} 秒")

用法：

with timer("sleep操作"): time.sleep(0.5) # 输出: sleep操作耗时: 0.5001 秒

原理上，装饰器把你的生成器函数包装成一个上下文管理器：yield之前的部分相当于__enter__，yield之后的部分相当于__exit__。yield传出去的值，就是as拿到的值。

如果需要在with块内引用一个资源，就把资源放在yield后面：

@contextmanager def managed_file(path, mode="r", encoding="utf-8"): f = open(path, mode, encoding=encoding) try: yield f finally: f.close() with managed_file("hello.txt", "r") as f: print(f.read())

这里yield f，as f得到的就是打开的文件对象。finally里的f.close()保证资源释放。

5.2 什么时候用装饰器，什么时候用类

我的判断标准很直接：

• 状态不需要在管理器外部复用的，用装饰器。比如计时、日志、临时属性修改，用完就丢。
• 需要对外暴露多个属性或方法的，用类。比如上面那个Timer，你可能想在with块内访问t.elapsed，class写法更清晰。
• 需要处理复杂异常逻辑、需要根据异常类型决定是否吞掉的，用类。装饰器写法里你只能在try...except...finally里手动做文章，不如__exit__的三个参数来得直接。

我在实际项目中大概八成的上下文管理器是用@contextmanager写的，只有少数需要精细异常处理的才写类。它最大的好处是把"进入-执行-退出"的样板从类的骨架中解放出来，直接摊开在函数里，读代码时非常直观。

6. 老手也会掉的坑：__exit__返回值、异常吞噬和事务边界

这章聊几个我实际排查过的坑。每一条都是"看着没问题，跑起来要命"的典型案例。

6.1 __exit__返回True，异常会被安静吃掉

这是最容易被忽略的行为。__exit__的返回值是布尔类型，含义是：返回True代表"我已经处理好了这个异常，解释器不要再管它了"；返回False或None，则异常继续向外传播。

看这个例子：

class IgnoreError: def __enter__(self): return self def __exit__(self, exc_type, exc_value, traceback): if exc_type is not None: print("捕获到异常，但我不打算往外抛") return True with IgnoreError(): raise ValueError("这是一个错误") print("这行能执行到，异常被吞了")

输出是：

捕获到异常，但我不打算往外抛 这行能执行到，异常被吞了

异常被__exit__吞掉是个危险行为。项目代码里出现异常却被静默忽略，后续排障时会一头雾水。所以默认情况下__exit__应该返回None，只有当你明确知道"这个异常就是要在这里处理掉、不需要上层感知"时才返回True。

我见过一个真实案例：有人用contextmanager写了一个suppress_errors装饰器，把整个业务函数包住，函数内部出错时__exit__返回了True。结果线上服务总是返回空结果但日志里没有任何异常记录，排查了两天才找到问题根源。用with做异常兜底前，先想清楚你是不是真的需要吞掉异常。

6.2 __exit__里的清理逻辑抛异常，会覆盖原始异常

这个坑藏得更深。假设你写了一个上下文管理器，__exit__里做资源清理时本身又抛了一个异常，那么with块内的原始异常会被顶掉，最终向外抛出的变成__exit__里的异常。调试时你会看到外层捕获的异常和代码真正的出错点八竿子打不着。

@contextmanager def broken_cleanup(): try: yield finally: raise RuntimeError("清理失败") try: with broken_cleanup(): raise ValueError("业务错误") except Exception as e: # 抛出来的是 RuntimeError，而不是 ValueError print(type(e).__name__, e)

输出是RuntimeError 清理失败，你的业务异常被掩盖了。在日志和监控系统里，你会看到一堆莫名其妙的RuntimeError，真正的业务错误完全丢失。解决思路有两个：

• 清理逻辑里用try...except Exception兜住，不能让它影响主流程异常。
• 在__exit__里拿到exc_value后，可以把它附加到新异常上，用raise RuntimeError("清理失败") from exc_value保留原始异常的上下文。

Python3里的raise ... from ...能把异常链串起来，排障效率高得多。

6.3 sqlite3的事务语义：前面提到过的完整排查链路

再展开讲一下数据库事务那个坑，因为这是我在工作中真正花了大半天排查的一个问题。

项目里有一段数据导入脚本，用到sqlite3：

conn = sqlite3.connect("import.db") for row in source_rows: conn.execute("INSERT INTO target VALUES (?)", (row,)) conn.close()

跑完脚本，打开数据库查，一条记录都没有。诡异的是，脚本执行过程中没抛任何异常。我做了如下排查：

1. 先确认SQL执行了。在for循环里加print(row)，数据确实打印出来了。
2. 确认没写错表。sqlite3命令行工具里SELECT COUNT(*) FROM target返回0。
3. 怀疑是不是隔离级别的问题。查了sqlite3.connect的isolation_level参数，默认是空字符串，说明开启了自动事务模式。
4. 查了官方文档才发现，sqlite3的自动提交和"关闭时自动提交"是两回事：在事务模式下执行execute后，必须显式调用commit()，或者让事务管理器来做；close()不会自动commit，而是回滚未提交的事务。

最后修复就是前面写过的with conn:方案。这个坑的教训不只是sqlite3，很多数据库驱动都有类似语义。用到哪个数据库，动手之前先看一遍官方文档里关于事务的部分，省下的时间远大于看文档的时间。

6.4 多锁顺序嵌套：with不是万能的并发安全卡

用with管理锁很简单，但多个锁同时出现时，嵌套顺序会引入死锁风险。线程A先锁L1再锁L2，线程B先锁L2再锁L1，两个线程就在互相等对方释放锁，谁也跑不下去。

with本身不会帮你解决死锁问题，它只是帮你保证acquire/release一定成对出现。所以如果你要在项目里拿多个锁，无论用不用with，都要规定好锁的获取顺序。这是个设计问题，不是语法问题。

7. 三个常见的"伪with"误区，以及一个能救命的工具

最后把这几个误区说透，顺便分享一个我常用的工具函数。

7.1 误区一：with只和文件有关

前文已经讲了，with是通用的上下文管理协议。只要对象实现了__enter__和__exit__，都可以用。文件、数据库连接、锁、socket、Session都只是这个协议的应用实例。反过来，一个没有实现协议的对象，哪怕它内部有close方法，直接写with obj:也会报AttributeError。

7.2 误区二：with会帮你"捕获异常"

这是个非常普遍的理解偏差。with本身不捕获异常。异常能不能被处理，取决于__exit__内部做了什么。如果__exit__没有特殊处理，异常会原样向外抛。换句话说，with open(...) as f:里如果读文件读到一半抛了异常，这个异常照样传到外层代码。

7.3 误区三：退出with之后，资源就一定被彻底清理了

大部分标准库对象在__exit__里确实是这么做的，但这是"约定"，不是"协议强制"。"上下文管理器协议"保证的是__exit__会被调用，至于它做什么，完全取决于实现者。你写一个__exit__什么都不干，照样不报错。所以拿到第三方库的对象时，别默认它的with行为就是"关闭"。

7.4 contextlib里的宝藏工具

contextlib模块里除了contextmanager，还有几个非常实用的工具。

contextlib.suppress用来临时忽略特定异常，比try...except更紧凑：

import contextlib with contextlib.suppress(FileNotFoundError): os.remove("可能不存在的文件.txt")

这个写法在清理临时文件、幂等操作里很爽。

contextlib.ExitStack适合动态管理数量不定的资源。它可以把任意多个__exit__回调收集起来，在with块结束时统一执行，顺序是后进先出。这在"运行时要根据条件决定打开几个文件或连接"的场景里是救命的。比如根据配置文件决定同时访问几个API，每个API对应一个Session，退出时全部关闭：

import contextlib import requests with contextlib.ExitStack() as stack: sessions = [] for endpoint in ["https://api1.example.com", "https://api2.example.com"]: s = requests.Session() stack.callback(s.close) sessions.append(s) # 业务处理，无论是否抛异常，退出时所有session都会close

ExitStack还有个好玩的能力是enter_context(manager)动态进入上下文管理器，和callback互补。

contextlib.redirect_stdout是我项目里经常用的：某段代码疯狂print，我想把输出重定向到日志文件或字符串缓冲区：

import contextlib import io buf = io.StringIO() with contextlib.redirect_stdout(buf): print("这条不会打到控制台，而是写进buf") print(buf.getvalue())

很多命令行工具做测试时都喜欢用这个来捕获输出。

最后再分享一个小技巧

with语句看似简单，但真正用好需要建立一套正确的"资源生命周期思维"：凡是获取了就必须释放的资源，第一反应都应该是"能不能用with管理"。文件、锁、数据库事务、网络连接，这四个场景用熟了，后面再遇到更复杂的资源管理，思路是通用的。

我个人写代码的习惯是，凡是涉及到"成对操作"的场景——打开/关闭、加锁/释放、进入/退出、开始/结束——都会优先考虑用上下文管理器封装。这个思维模式用到后面，你会发现不是"Python里有with所以我要用"，而是"这个资源有明确的生命周期，with恰好是最贴合的表达方式"。希望这篇文章能帮你在写Python时少踩几个坑，多省点时间。