先问一个很实在的问题：你最近一次用with open(...) as f:是什么时候？我猜大概率是今天——因为只要写Python，读写文件、操作数据库、拿锁、开网络连接，这套语法几乎是绕不开的“基础动作”。但绝大多数人只是“会用”，真被问到“with语句到底做了什么、__enter__和__exit__协议如何起效、为什么它比try/finally更优雅”，反而容易卡壳。
这篇文章不打算重复官方文档，我想从原理讲起，结合我自己项目里踩过的坑，把上下文管理器（with语句）的执行机制、自定义实现的三种主流方式、以及那些在线文档里很少提到的陷阱一次性讲透。无论你是刚毕业的新人，还是已经写了三五年业务代码的开发者，只要你和资源打交道，这篇都值得花十分钟看完。与其说它是一篇教程，不如说是一份“上下文管理器避坑指南”。
1. 功能拆解：with到底解决了什么问题
1.1 资源泄漏是每个人踩过的雷
程序里最常见的资源泄漏场景，我闭着眼都能背出来：打开文件后忘了close()。Windows用户感受最深，文件被占用导致删除失败；Linux服务器上则是文件描述符（fd）被一点点耗尽，最终open()直接报Too many open files。
新手写代码最容易出现这种模式：
f = open("data.txt", "r") data = f.read() # 忘写 f.close()稍微有点经验的同学会补上try/finally：
f = open("data.txt", "r") try: data = f.read() finally: f.close()这段代码本身没有毛病，但只要你同时管理多个资源，嵌套就会变得很难看。再往后，很多人就养成了“能写with就写with”的习惯。核心原因很简单：with把“资源获取时的准备工作”和“代码块结束后的清理动作”绑定在一起，让清理逻辑在视觉上被压缩到一行，不再靠开发者的自觉。
1.2 with语句的执行过程到底是什么
用一句话说，with是“在进入代码块前做准备工作，在退出代码块后做清理工作”的语法糖。但它的真实执行顺序，很多人其实没有完整理解。以这句代码为例：
with open("data.txt", "r") as f: data = f.read()它的执行过程可以分为五步：
- 先求值
open("data.txt", "r")，得到一个文件对象。 - Python自动调用这个对象的
__enter__()方法，把进入上下文时该做的准备做完。open()返回的文件对象，它的__enter__()直接返回自身，所以as f拿到的就是文件对象本身。 as f把__enter__()的返回值绑定到变量f上。- 执行缩进代码块中的内容（
data = f.read()）。 - 无论代码块正常结束还是抛异常，Python都会自动调用对象的
__exit__()方法，在这里完成f.close()。
很多人会忽略一个细节：with后面的对象并不一定要自己实现上下文管理器协议，只要它“产生”出的对象实现了协议就行。比如标准库里很多类就是让工厂函数返回的对象去实现__enter__/__exit__。这个设计让API的灵活性提升了一个层级。
我之前培训过一位新同事，他以为as f里的f就是with表达式求得的值，后来发现其实f是__enter__()的返回值。这个理解如果不纠正，后面写自定义上下文管理器时会踩不少坑。准确理解协议顺序，是玩转with的第一个门槛。
2. 协议核心：__enter__和__exit__的约定与陷阱
2.1 协议是怎么运作的
上下文管理器协议由两个魔法方法组成，任何对象只要实现它们，就能配合with语句工作：
__enter__(self)：进入上下文时被调用，通常负责获取资源、打开连接、加锁；返回值会通过as绑定到目标变量。如果不写as，返回值就被直接丢弃。__exit__(self, exc_type, exc_value, traceback)：退出上下文时被调用，负责释放资源、关闭连接、解锁。
需要特别注意的是__exit__的三个参数：exc_type是异常类型，exc_value是异常实例，traceback是堆栈对象。这三个参数只有在代码块内部抛出异常时才会有值；如果代码块正常结束，三者都是None。这点在设计上下文管理器时非常关键，它让你有能力在退出前“感知”到异常。
一个常见误区是：__enter__和__init__的关系。很多人写自定义管理器时，喜欢把资源获取放在__init__里，把释放放在__exit__里。这没有绝对的对错，但你要理解两者的差异：__init__在with语句被求值之前就执行了，如果__init__里抛异常，整个过程根本不会进入with代码块；而__enter__是在进入with块之前一刻才执行，两者在异常处理时机上有微妙区别。
我实战中推荐的原则是：对象的构建逻辑放在__init__，进入上下文的准备逻辑放在__enter__。这样对象可以独立存在，也方便在特殊场景下不依赖with去手动准备和释放。
2.2__exit__返回值的玄机
这是网上资料讲得最少、但实际项目里最容易出问题的地方。__exit__()方法的返回值，决定了异常是否被“吞掉”：
- 返回
True，表示异常已经被处理，with代码块内部的异常不会继续向外传播。 - 返回
False（或者返回None，因为没有显式return时默认就是None），异常会照常抛出。
什么意思？看这个例子：
class IgnoreValueError: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): return exc_type is ValueError with IgnoreValueError(): raise ValueError("这会被静默吞掉") print("后面的代码仍然执行")这样写，ValueError会被__exit__的返回值True拦住，程序不会崩溃。听起来很强大对吧？但我必须告诫一句：这是双刃剑，非必要不要用。因为吞掉异常等于隐藏故障，排查问题时你会陷入“明明代码没报错，结果却不对”的泥潭。
我见过的合理用法，都是带条件的。比如某个旧接口偶尔抛出可预期的、无伤大雅的异常，你希望在这个上下文里自动忽略，但其他异常要照常抛。即便如此，我也建议在__exit__里额外打印一条日志，而不是无声无息地吞掉。记住一条铁律：“异常可以是业务的一部分，但沉默不能是。”
3. 实操指南：三种自定义上下文管理器的写法
3.1 基于类的实现：最原始也最清晰
先看最经典的类实现。假设我要写一个“带启动和停止逻辑的数据库连接”的上下文管理器：
class DatabaseConnection: def __init__(self, dsn): self.dsn = dsn self.connection = None def __enter__(self): print("开始建立连接") self.connection = connect(self.dsn) return self.connection def __exit__(self, exc_type, exc_val, exc_tb): print("关闭连接") if self.connection: self.connection.close()使用时就变得非常干净：
with DatabaseConnection("postgres://...") as conn: cursor = conn.execute("SELECT 1")类实现的好处是直观，不需要理解生成器也能写；坏处是代码量稍大，如果只是临时用一次，会显得笨重。而且记得__exit__里不要随便返回True——上面提到的陷阱在这里同样适用，除非你真的想吞异常，否则让它隐式返回None就好。
如果要在__exit__中做“发生异常时回滚事务、正常时提交事务”的逻辑，可以这样：
def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is None: self.connection.commit() else: self.connection.rollback() self.connection.close()这是事务型上下文管理器最标准的内核。注意这里没有return，所以异常依然会向外部传播，数据库本身的回滚动作已经被我们顺手完成了。
3.2 基于生成器的contextmanager：最常用的简洁方案
如果你觉得写类太啰嗦，contextlib.contextmanager装饰器就是来拯救你的。它允许把一个生成器函数包装成上下文管理器，内部逻辑从上到下依次对应__enter__和__exit__：
from contextlib import contextmanager @contextmanager def managed_file(filename): f = open(filename, "r") try: yield f finally: f.close()这里的关键是yield：yield前是“进入上下文”的逻辑，yield后是“退出上下文”的逻辑。as绑定的变量就是yield出来的值。用起来和类版本一模一样。
用contextmanager有一个非常容易踩的坑：yield外面一定要包try/finally。我之前见过一个同事这么写：
@contextmanager def bad_context(): resource = acquire() yield resource release()表面上看没问题，但如果yield时代码块抛异常，release()永远执行不到。正确做法是用try/finally包裹yield，确保无论是正常退出还是异常退出，资源都能被释放。这就是“你不需要记住每次都要写finally，但生成器内部务必要用finally”的原则。
而且，用contextmanager时，如果yield后抛异常，__exit__会被调用；但如果你在生成器内部捕获了异常然后再次抛出，要小心异常链信息丢失。最稳妥的方式就是让异常自然传播，不干预，除非有明确需求并做好记录。
3.3 关键时刻使用ExitStack管理不确定数量的资源
前面说的都是“写代码时就知道有几个资源”的情况。但在实际项目里，我遇到过更复杂的场景：资源数量不固定，需要循环打开一批文件，或者根据不同配置动态注册退出回调。这时候ExitStack就派上用场了。
from contextlib import ExitStack with ExitStack() as stack: for filename in file_list: f = open(filename, "r") stack.enter_context(f) # 在这里统一处理所有打开的文件 do_something() # 退出后自动关闭所有进入过上下文的资源ExitStack的核心能力是“动态注册”：你把每个资源通过enter_context()交给它，它内部维护一个栈，到了退出时按后进先出的顺序依次调用__exit__。如果你需要注册一个不依赖with协议的清理动作，还可以直接用stack.callback(func)。
这个工具特别适合那些“循环里中途可能break或continue”的场景。手动管理会导致清理逻辑写得像迷宫，用ExitStack之后，心态稳定很多：只要资源被成功注册进stack，退出时一定被清理。以及，ExitStack也支持用pop_all()把已注册的资源“弹出去”交给别人，这在写某些回调框架时很有用，不过日常开发中用得比较少。
3.4 异步上下文管理器不能忘
Python从3.7之后越来越强调异步编程，很多awaitable的资源（比如aiohttp的ClientSession、异步数据库连接池）无法用普通的with管理，必须使用async with和另一对魔法方法：__aenter__和__aexit__。
class AsyncSession: async def __aenter__(self): self.session = await create_session() return self.session async def __aexit__(self, exc_type, exc_val, exc_tb): await self.session.close()用法：
async with AsyncSession() as session: await session.get("https://example.com")有一点要注意：async with和with不能混用。async with只认__aenter__/__aexit__，普通with只认__enter__/__exit__。如果未来要做一个“同步异步都能用”的上下文管理器，需要同时实现两对协议方法，而且实现时要小心同步版本不处理异步资源。这算是一个进阶话题，但至少你现在应该知道异步版本的概念，才不会在asyncio生态里写出阻塞型上下文管理器。
4. 实战场景：代码比文档更有说服力
4.1 用上下文管理器封装“超时与清理”业务
我在一个项目里需要频繁调用某个第三方API，但它的连接偶尔会短暂不可用。为了不污染主流程，我写了一个带重试和超时清理的上下文管理器：
@contextmanager def api_session(total_timeout=3): session = requests.Session() session.timeout = total_timeout try: yield session except requests.exceptions.Timeout as e: log.warning("API请求超时，尝试清理连接: %s", e) session.close() raise finally: session.close()这里except用来感知异常并记录，finally保证连接一定关闭。调用方就可以这样写：
with api_session(timeout=5) as sess: resp = sess.get(url)这种封装的精髓在于：调用方不需要关心session的关闭逻辑，只需要关注业务本身。同时，因为异常没有被吞掉，上层可以正常感知超时并决定要不要重试。
4.2 日志和指标的自动打点
如果你正好需要统计一段代码的执行时间，上下文管理器是非常自然的载体：
from time import perf_counter @contextmanager def timing(name): start = perf_counter() try: yield finally: elapsed = perf_counter() - start print(f"{name} 耗时: {elapsed:.3f}s")这种写法比手动记录开始结束时间干净得多，而且天然支持嵌套。我在做性能分析时经常把不同环节用不同的timing包起来，读代码时每个块耗时一目了然。
不要觉得“包一层上下文管理器会让代码变得很重”，实际上with的开销极其有限，它不是你运行时的性能瓶颈。真正消耗性能的是资源获取与释放本身。如果你发现一个上下文管理器拖慢了程序，先检查资源操作是否过于频繁，而不是先怀疑with语法。
4.3 关于锁和并发控制的标准姿势
在多线程环境里，threading.Lock自身实现了上下文管理器协议，所以常写：
lock = threading.Lock() with lock: # 临界区代码 shared_counter += 1这比lock.acquire()/lock.release()好看太多，关键是即使临界区抛异常，锁也一定被释放，不会出现死锁。类似的，multiprocessing里的一些同步原语也支持with。我的经验是：只要是“成对出现”的资源操作——开与关、锁与释放、订阅与取消订阅，都值得用上下文管理器封装。
5. 常见问题与排查笔记
5.1 我明明写了with，为什么资源还是泄漏了
排查思路要挨个过。首先确认你用的是真正的资源对象，而不是返回的新对象。如果__enter__里返回的是一个拷贝或包装对象，而__exit__却是释放最外层对象的资源，那就可能出现“内层对象没有被关闭”的情况。
另一个常见原因是：with表达式里的求值过程抛了异常，导致__enter__压根没被调用，资源已经在构造函数中打开却无人释放。解决方法是把资源获取也放进__enter__，而不是全放在__init__。比如：
class Bad: def __init__(self): self.f = open("a.txt") # 如果open前抛异常，f可能没被赋值这种写法问题很大。换成只在__enter__中打开资源，至少能保证一旦with成功进入，__exit__一定会被调用。
5.2 异常被__exit__静默吞掉，如何排查
如果你的代码突然变得“不报错但还是不对”，先检查上下文管理器的__exit__返回值。经验做法是：永远不要在你的自定义__exit__里无脑return True。如果确实需要吞某些异常，至少加日志：
def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is OSError: logger.warning("忽略OSError: %s", exc_val) return True return False只有明确知道“这个异常不影响主流程”时才这么干。排查时，可以用下面这段临时验证：
with IgnoreValueError(): raise ValueError("test")如果不打印任何异常信息且后续代码正常执行，基本可以确认是__exit__返回了True。
5.3 with块里的return、break、continue，__exit__都会被调用吗
这三类情况确实都会触发__exit__。这是with与try/finally相比更可靠的原因。举例：
def demo(): with open("a.txt") as f: return f.read()虽然函数在with块内直接返回了，但文件关闭逻辑依然会被执行，不会因为return而跳过清理。同理，循环里的break和continue也不会让清理逻辑“逃逸”。这种确定性，是上下文管理器在资源管理场景成为首选的最重要理由。
反过来也要小心：不要在__exit__里执行耗时操作，比如复杂的网络清理或同步等待，否则即使主逻辑早已return，程序依然会在这里“停留”。异步上下文管理器的__aexit__尤其容易被人放大量await逻辑，需要注意耗时问题。
5.4 多个资源如何优雅地一起管理
除了嵌套使用，更推荐用逗号分隔的写法：
with open("a.txt") as f1, open("b.txt") as f2: # 同时操作两个文件如果代码块中途抛出异常，两个文件都会被正确关闭。需要注意的语义是：这段代码等价于嵌套的with，但可读性更好，Python官方也支持这种写法。唯一要注意的是资源数量不要太多，五六个以上建议改用ExitStack或重新设计结构，否则代码依然会变得难读。
6. 一些实践经验与最后的建议
6.1 什么时候不该用with
虽然with很强大，但也不是万能的。它适合“有明确进入和退出阶段”的场景。如果你的资源生命周期跨越多个函数、多个循环，甚至贯穿整个进程，硬套with反而会让生命周期更加混乱。比如数据库连接池中的连接，连接池本身负责持有和复用连接，这时候把连接放进单次with里可能频繁建立/释放，性能反而下降。
还有一点：不要把重量级业务逻辑全部塞进__exit__里。__exit__的本职是“清理”，不是“事后处理器”。我在一个项目里见过同事把发送通知、写审计日志的代码全放在__exit__里，结果代码一异常，通知逻辑也跟着变得异常难排查，最终重构后回归，“清理就是清理”，职责边界清晰很重要。
6.2 从框架层面思考with的价值
很多人觉得上下文管理器就是“打开文件、关闭文件”的小工具，但往深了想，它其实是Python对“资源生命周期”的一种语言级抽象。它能让你把“获取”和“释放”做成一对不可拆分的动作，同时保留对异常的感知和处理能力。这种抽象，在写业务代码时是“用着顺手”，在写基础库和框架时就是“立身之本”——标准库里的事务、锁、mock环境、临时目录，几乎全是靠这套协议实现的。
我个人的体会是，理解了__enter__/__exit__这套协议之后，再回头去看很多框架源码，很多原先看不懂的封装逻辑会突然踩通了。它不只是一个语法点，更像是一把打开Python资源管理体系的钥匙。如果你今天只记住一句话，那我希望是：“资源管理永远有收尾，收尾永远用with；如果要吞异常，请先留下日志。”
