从写第一行with open(...)开始到真正弄懂它背后那套协议我大概花了两年时间。前两年我只是把它当自动关闭文件的快捷键直到有一次线上服务文件句柄被耗尽我才认真去研究with背后的上下文管理器到底做了什么。这篇文章不绕弯子直接讲清楚上下文管理器Context Manager的原理、三种实现方式、典型应用场景和我在真实项目里踩过的一系列坑适合刚学完 Python 基础、想写出更健壮代码的人也适合用了一段时间with但始终没搞懂__enter__/__exit__的老手。1. 从忘记关闭资源说起为什么需要上下文管理器1.1 一个最容易翻车的示例文件操作与资源泄漏很多人的 Python 入门第一课就是读写文件老师通常会教这一句f open(test.txt, w) f.write(hello) f.close()看起来没毛病但问题在于如果f.write(hello)在执行过程中抛了异常f.close()根本不会执行。文件对象会一直留在内存里操作系统分配的文件描述符也不会释放。写得多的小脚本无所谓可一旦放到服务端程序里反复打开文件不关闭最终会触到操作系统的文件句柄上限然后整个进程开始抛OSError: [Errno 24] Too many open files。这时候新手的第一反应是那我用try...finally总行吧。于是代码变成了f open(test.txt, w) try: f.write(hello) finally: f.close()这确实能解决问题但每次处理一个资源都要套一层try/finally代码会变得很丑嵌套一多就看不下去。with语句正是为了解决这类问题设计的——它把获取资源、执行代码、释放资源这三个动作包装成了一个干净利落的语法结构。with open(test.txt, w) as f: f.write(hello)文件对象在执行完with代码块后自动关闭哪怕代码块里抛出异常close()也会被执行。这种替你把善后工作做了的对象就是上下文管理器。1.2 资源泄漏的代价文件句柄、数据库连接、锁的真实损耗很多人觉得资源泄漏是以后再说的小事其实它的代价比想象中来得快。我用自己的笔记本做过一次极端实验写一个循环每次打开文件但故意不关闭跑到几千次之后系统就开始报Too many open files。在 Linux 系统上单个进程的默认文件描述符上限通常是 1024这数字听起来不少但在高并发的服务里每个请求开两三个文件、连一两个数据库二三百个并发就能把上限打满。数据库连接资源更贵。客户端与 MySQL 建立连接需要 TCP 握手、认证、分配内存一个连接可能占用几 MB 的服务器端资源。如果每次查询都忘记归还连接连接池很快耗尽。我这里有个真实的线上教训有一次一个定时任务里循环处理十万条订单每条数据查询一个 MySQL但连接没有归还跑到大概两千条时数据库连接池全部被占满其它业务接口全部超时。排查到最后就是少了with或者finally。锁资源也不能忘。Python 的threading.Lock一旦acquire()却没release()其他线程就会永远卡在等待上。如果是程序启动时死锁整锅服务全部停摆。这些问题用上下文管理器都能在结构上规避——把资源的生命周期绑定到with代码块上代码块结束资源自动归还。2. 上下文管理器的工作原理with 的真面目2.1 魔法方法__enter__与__exit__协议的核心with语句背后其实是一个协议任何对象只要实现了__enter__和__exit__这两个方法就可以被with管理。这两个方法是 Python 数据模型里的魔法方法你可以把它们理解成一个进入和退出的钩子。Python 解释器执行with obj as var:这句时会先调用obj.__enter__()把该方法返回的值绑定到as后面的变量上。当with代码块执行完毕无论正常结束还是异常终止解释器都会调用obj.__exit__(exc_type, exc_val, exc_tb)。__exit__的三个参数分别代表异常类型、异常实例和 traceback 对象。如果没有发生异常这三个参数都是None。如果出现了异常它们就携带异常信息。__exit__有一个关键的返回值返回True表示异常我已经处理了你不要再往外抛返回False或None表示异常继续向上传播。用一个极简的自定义对象来演示class ManagedFile: def __init__(self, name): self.name name def __enter__(self): print(进入 with 代码块) self.file open(self.name, w) return self.file def __exit__(self, exc_type, exc_val, exc_tb): print(退出 with 代码块) if self.file: self.file.close() return False with ManagedFile(demo.txt) as f: f.write(hello)运行这段代码会看到先打印进入再打印退出。如果把f.write改成抛异常依然会打印退出因为无论代码块内发生了什么__exit__都会被调用。这就是with最核心的价值保证退出动作一定会执行。2.2 with 语句的完整执行流程与三种例外情况with的执行流程可以拆成四步计算with后面的表达式得到上下文管理器对象例如执行open(...)得到一个文件对象文件对象本身就是上下文管理器。调用对象的__enter__()把返回值赋值给as后的变量。如果不用as返回值被丢弃但__enter__依然会被调用。执行with代码块主体。无论主体是否抛出异常调用__exit__(exc_type, exc_val, exc_tb)。第 4 步有几种分支情况很多人第一次看容易绕晕我整理成了一张速查表场景__exit__接收的参数__exit__返回 True__exit__返回 False/None代码块正常结束(None, None, None)正常结束无异常正常结束无异常代码块抛异常异常的 type/value/traceback异常被吞掉代码块后的代码继续执行异常继续向上抛出__enter__本身抛异常不调用__exit__无无有一种例外情况值得单独强调如果异常发生在__enter__方法内部__exit__不会被执行因为对象根本没有成功进入。这其实很好理解就像你进商场刷卡了但闸机坏了你还没进到商场里面商场自然不会负责送你出门。另一种情况是__exit__自己抛了异常那么这个新异常会替代原来的异常继续向外传播。所以别在__exit__里写可能出错的清理逻辑而不做内部保护。参考 Python 官方文档对with语句语义的说明用try/finally来模拟with是最直观的manager open(demo.txt, w) var manager.__enter__() try: var.write(hello) finally: manager.__exit__(None, None, None)当然这是简化模型实际的异常参数传递比这个复杂但理解到这层已经够用。3. 三种实现上下文管理器的主流方案3.1 基于类实现把__enter__/__exit__写清楚最传统、也最容易理解的方式是定义一个类实现两个魔法方法。适合需要保存状态、需要精细管理资源的场景。class Timer: def __enter__(self): import time self.start time.perf_counter() return self def __exit__(self, exc_type, exc_val, exc_tb): self.elapsed time.perf_counter() - self.start print(f耗时 {self.elapsed:.6f} 秒) return False使用时with Timer(): sum(range(1000000))类方式的好处是清晰、可复用、可以在__init__里收参数。缺点是样板代码稍多每个上下文管理器都要写四个方法__init__、__enter__、__exit__、通常还有别的。如果你只是临时想测一段代码的执行时间完全没必要专门造一个类。类方式还有一个常见用途把__enter__返回值设计成自己方便在with代码块里访问上下文属性。上面例子就是这样with Timer() as t:之后t就是Timer实例本身代码块里可以随时访问t.start。3.2 基于contextlib.contextmanager与yield更短的代码Python 的contextlib模块提供了一个装饰器contextmanager让你不用写类也能生成上下文管理器。核心逻辑是用一个生成器函数配合yield切分进入和退出yield之前的代码对应__enter__yield语句本身把返回值交给as变量yield之后的代码对应__exit__from contextlib import contextmanager contextmanager def managed_file(name): f open(name, w) try: yield f finally: f.close() with managed_file(demo.txt) as f: f.write(hello)注意看yield被try/finally包裹。这个finally很重要它保证即使with代码块里抛了异常f.close()也会执行。用contextmanager装饰时yield后面的代码实际上会被包装进__exit__的逻辑里如果yield之前初始化失败后面代码不会执行这与类实现的__enter__抛异常不调用__exit__一致。contextmanager的写法简洁很多特别适合一次性的、小型的上下文管理需求。我自己在项目里大部分场景都用它只有需要复杂状态时才会回到类实现。3.3 标准库自带的高频上下文管理器Python 标准库里面已经内置了大量上下文管理器拿过来就能用不需要自己实现。最常被用到的是open()返回的文件对象。第二个高频货是threading.Lockimport threading lock threading.Lock() # 传统写法 lock.acquire() try: # 临界区 pass finally: lock.release() # with 写法 with lock: # 临界区 passcontextlib.closing也很有用。有些资源对象自带close()但没有实现上下文管理器协议比如一个自定义的网络客户端。closing包装后就可以用with管理from contextlib import closing class SomeClient: def close(self): print(资源关闭) def query(self): return data with closing(SomeClient()) as client: print(client.query())标准库还有一个contextlib.redirect_stdout我调试时经常用它把 print 输出重定向到文件或字符串import io from contextlib import redirect_stdout buf io.StringIO() with redirect_stdout(buf): print(这段内容会写入缓冲区) output buf.getvalue()contextlib.suppress也很香。它专门用来吞掉指定的异常比try/except: pass更直观from contextlib import suppress with suppress(FileNotFoundError): os.remove(nope.txt)如果nope.txt不存在suppress会把它吞掉程序不报错。这个用法在清理临时文件时非常省心。4. 实操案例把上下文管理器用进真实项目4.1 计时器一个能反复用的性能检测工具先说一个最简单的实用案例。我在做接口性能优化时经常要测一小段逻辑的耗时。传统写法是手动记录两个时间点然后相减。有了contextmanager可以做成一个可以反复用的计时器import time from contextlib import contextmanager contextmanager def timeit(labelelapsed): start time.perf_counter() try: yield finally: elapsed time.perf_counter() - start print(f{label}: {elapsed:.4f}s) with timeit(查询订单): orders query_orders()这段代码的核心在于time.perf_counter()。它比time.time()精度更高特别适合测量短耗时操作。finally里的打印保证了即使代码块中途异常退出耗时也能显示出来方便我们定位到底是哪次异常导致性能问题。4.2 数据库事务与连接管理把 commit/rollback 写进上下文数据库操作是上下文管理器的重头戏。一个连接从获取、执行 SQL、到提交或回滚、最后归还连接整个生命周期串下来中间任何一环出错都会造成数据不一致或连接泄漏。我习惯把连接获取 事务控制一起封装from contextlib import contextmanager import pymysql contextmanager def db_transaction(conn_config): conn pymysql.connect(**conn_config) try: yield conn conn.commit() # 代码块正常结束提交事务 except Exception: conn.rollback() # 代码块抛异常回滚事务 raise # 异常继续抛给上层 finally: conn.close() # 无论是否异常连接都要归还 with db_transaction(MY_CONFIG) as conn: with conn.cursor() as cursor: cursor.execute(UPDATE account SET balance balance - 100 WHERE id 1) cursor.execute(UPDATE account SET balance balance 100 WHERE id 2)这里有几个细节值得注意。第一conn.cursor()本身也是上下文管理器所以可以嵌套with。第二yield返回的是连接对象上层代码拿到它直接执行 SQL。第三commit()写在yield之后意味着只有代码块没有异常才会提交一旦有异常会走except分支回滚。第四raise不能省否则异常被吞上层无法感知失败。这个模式囊括了事务的 ACID 特性非常实用。4.3 临时切换环境目录、环境变量与 PATH有时候你需要临时修改进程的全局状态比如切换工作目录。手动切换的痛点是容易忘记切回来。os.chdir()切换后如果代码报错后续代码还运行在原目录的假设下定位问题极其痛苦。用上下文管理器可以自动还原import os from contextlib import contextmanager contextmanager def working_directory(path): cwd os.getcwd() os.chdir(path) try: yield finally: os.chdir(cwd) with working_directory(/tmp): # 当前目录是 /tmp pass # 退出后自动回到原来的目录同理临时修改环境变量、临时追加PYTHONPATH都可以用这个模式。关键点是先把旧值保存下来yield之后再恢复。finally保证即使代码块异常环境也不会被污染。这一类上下文管理器在写测试、跑数据迁移脚本时特别好用。4.4 嵌套 with 与管理多个资源ExitStack 的优雅解法实际项目中经常要同时打开多个资源。初学者喜欢一层套一层with open(a.txt) as fa: with open(b.txt) as fb: pass层次浅还好资源一多就变成金字塔代码很不雅观。Python 3.10 之前相同层级的资源可以写在同一行用逗号分隔with open(a.txt) as fa, open(b.txt) as fb: pass但如果资源的数量是动态的比如一个列表里有 10 个文件要同时打开就不能静态写在with里了。这时候要上contextlib.ExitStackfrom contextlib import ExitStack file_paths [a.txt, b.txt, c.txt] with ExitStack() as stack: files [stack.enter_context(open(path)) for path in file_paths] # 这里的 files 是三个文件对象全部可用 # 退出 with 块时三个文件按后进先出顺序自动关闭ExitStack的原理是动态注册退出回调。你可以注册任意数量的上下文管理器在with块结束时按栈的顺序统一清理。它尤其适合在函数里收集各种资源再统一释放的场景。我写测试框架时经常用ExitStack临时 push 一堆 mock 对象退出代码块自动全部撤销比手写 try/finally 干净得多。5. 常见问题与排查技巧实录5.1__exit__返回值为什么容易被忽略最常见的坑是你以为__exit__里的异常处理生效了但实际上它return True把异常吞了上层完全不知道失败。来看这个例子class IgnoreAll: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): print(exit called) return True with IgnoreAll(): raise ValueError(something wrong) print(程序继续执行)这段代码会打印exit called再打印程序继续执行异常完全被吞。在某些场景下这是故意为之但更多时候是意外的——比如你在__exit__里写了return self本意是返回对象但__exit__的返回值会被当作布尔值处理self非空即True结果异常被吞掉排查问题找半天找不到原因。我的建议是除非明确知道自己在做什么否则__exit__都应该return False或return None让异常继续往外抛。如果真想吞掉至少加一行注释说明意图。5.2 生成器实现的上下文管理器抛异常后怎么办使用contextmanager时yield之间的代码如果抛异常要明白异常会直接传到调用方。但有个容易踩的细节如果yield之后的清理代码抛了异常这个异常会替代原始异常掩盖真正的问题。举个例子contextmanager def buggy(): try: yield finally: 1 / 0 # 清理代码本身出错 with buggy(): raise ValueError(原始异常)在这个场景中调用方看到的是ZeroDivisionError而不是原始的ValueError。清理代码抛出的异常会覆盖业务代码的异常。解决办法是清理逻辑也要包一层防护至少记录下来原始异常。我在做资源清理时会先在except里保存异常信息清理代码尽量只做简单操作防止误伤。5.3 不要用with open读大文件的一个误区很多人觉得with open(big.txt) as f:能自动管理资源就放心地data f.read()。但对好几 GB 的大文件一次性read()会直接把内存打爆。with负责的是文件句柄的释放不负责内存的管控。大文件应该逐行或分块读取with open(big.txt) as f: for line in f: process(line)如果必须一次性读取部分块可以用f.read(1024 * 1024)循环读。另外注意with只保证文件对象生命周期结束并不等于全部内容都安全内存问题要根据数据量单独设计。5.4 上下文管理器与装饰器的搭配contextmanager 的边界contextmanager不但能装饰普通生成器函数还能与装饰器结合实现装饰器 上下文的双重能力。一个常见的组合是在装饰器里包裹上下文from functools import wraps from contextlib import contextmanager contextmanager def log_errors(): try: yield except Exception as e: print(f捕获异常: {e}) raise def logged(func): wraps(func) def wrapper(*args, **kwargs): with log_errors(): return func(*args, **kwargs) return wrapper这里logged装饰器把函数调用包在上下文管理器里。好处是逻辑复用日志逻辑和业务逻辑解耦。但注意不要滥用contextmanager装饰的生成器函数一旦yield之后抛出异常该异常同样会传播给调用方所以装饰器里如果再包一层try/except就要小心异常的层级关系。5.5 上下文管理器别忘了处理as变量作用域with open(a) as f:里的f在退出with块后依然存在但它指向的文件对象已经关闭。很多人误以为出了with块变量就没了其实 Python 根本没有块级作用域。这意味着退出后如果误用了f会得到ValueError: I/O operation on closed file。我建议在with块结束后立即置空或者明确不再使用该变量。如果需要在with块外面继续保留数据把数据复制到普通变量里不要让资源对象逃逸出去。这个细节在写复杂函数时很容易引发隐蔽 bug。6. 实战收尾我的经验与习惯写上下文管理器这几年我个人最常用的其实是contextmanagerExitStack的组合。contextmanager负责把繁琐的清理逻辑压缩成几行代码ExitStack负责管理数量不定的资源两者配合几乎能覆盖我遇到的所有场景。类实现虽然规范但大多数业务里用不上那么重的抽象。还有一个很多人不知道的小技巧contextlib里有个ContextDecorator可以让你的上下文管理器直接当装饰器用。如果你设计的with块本身没有对外部状态的依赖那么把__enter__和__exit__写到类里并继承ContextDecorator同一个类既能用于with也能用于装饰函数一鱼两吃。最后说一个实际的体会上下文管理器最忌讳的是做太多。它本质上是资源的守卫不是业务逻辑的容器。我见过有人把整个接口的业务逻辑全塞进一个巨大的with块说这样自动回收所有资源。这种写法会让代码极难阅读而且一旦__exit__里动作过多任何一个清理错误都会拉垮整个调用链。保持__enter__精简、__exit__稳定、yield之间的代码短小才是真正用好上下文管理器的秘诀。希望这篇整理对你有用下次写资源相关代码时多想想with帮你挡住了哪些坑。 
长河君 · 2026/10/7 4:44:33 · 阅读 1.2k 深入理解Python上下文管理器：with、__enter__与__exit__实战指南
从写第一行with open(...)开始到真正弄懂它背后那套协议我大概花了两年时间。前两年我只是把它当自动关闭文件的快捷键直到有一次线上服务文件句柄被耗尽我才认真去研究with背后的上下文管理器到底做了什么。这篇文章不绕弯子直接讲清楚上下文管理器Context Manager的原理、三种实现方式、典型应用场景和我在真实项目里踩过的一系列坑适合刚学完 Python 基础、想写出更健壮代码的人也适合用了一段时间with但始终没搞懂__enter__/__exit__的老手。1. 从忘记关闭资源说起为什么需要上下文管理器1.1 一个最容易翻车的示例文件操作与资源泄漏很多人的 Python 入门第一课就是读写文件老师通常会教这一句f open(test.txt, w) f.write(hello) f.close()看起来没毛病但问题在于如果f.write(hello)在执行过程中抛了异常f.close()根本不会执行。文件对象会一直留在内存里操作系统分配的文件描述符也不会释放。写得多的小脚本无所谓可一旦放到服务端程序里反复打开文件不关闭最终会触到操作系统的文件句柄上限然后整个进程开始抛OSError: [Errno 24] Too many open files。这时候新手的第一反应是那我用try...finally总行吧。于是代码变成了f open(test.txt, w) try: f.write(hello) finally: f.close()这确实能解决问题但每次处理一个资源都要套一层try/finally代码会变得很丑嵌套一多就看不下去。with语句正是为了解决这类问题设计的——它把获取资源、执行代码、释放资源这三个动作包装成了一个干净利落的语法结构。with open(test.txt, w) as f: f.write(hello)文件对象在执行完with代码块后自动关闭哪怕代码块里抛出异常close()也会被执行。这种替你把善后工作做了的对象就是上下文管理器。1.2 资源泄漏的代价文件句柄、数据库连接、锁的真实损耗很多人觉得资源泄漏是以后再说的小事其实它的代价比想象中来得快。我用自己的笔记本做过一次极端实验写一个循环每次打开文件但故意不关闭跑到几千次之后系统就开始报Too many open files。在 Linux 系统上单个进程的默认文件描述符上限通常是 1024这数字听起来不少但在高并发的服务里每个请求开两三个文件、连一两个数据库二三百个并发就能把上限打满。数据库连接资源更贵。客户端与 MySQL 建立连接需要 TCP 握手、认证、分配内存一个连接可能占用几 MB 的服务器端资源。如果每次查询都忘记归还连接连接池很快耗尽。我这里有个真实的线上教训有一次一个定时任务里循环处理十万条订单每条数据查询一个 MySQL但连接没有归还跑到大概两千条时数据库连接池全部被占满其它业务接口全部超时。排查到最后就是少了with或者finally。锁资源也不能忘。Python 的threading.Lock一旦acquire()却没release()其他线程就会永远卡在等待上。如果是程序启动时死锁整锅服务全部停摆。这些问题用上下文管理器都能在结构上规避——把资源的生命周期绑定到with代码块上代码块结束资源自动归还。2. 上下文管理器的工作原理with 的真面目2.1 魔法方法__enter__与__exit__协议的核心with语句背后其实是一个协议任何对象只要实现了__enter__和__exit__这两个方法就可以被with管理。这两个方法是 Python 数据模型里的魔法方法你可以把它们理解成一个进入和退出的钩子。Python 解释器执行with obj as var:这句时会先调用obj.__enter__()把该方法返回的值绑定到as后面的变量上。当with代码块执行完毕无论正常结束还是异常终止解释器都会调用obj.__exit__(exc_type, exc_val, exc_tb)。__exit__的三个参数分别代表异常类型、异常实例和 traceback 对象。如果没有发生异常这三个参数都是None。如果出现了异常它们就携带异常信息。__exit__有一个关键的返回值返回True表示异常我已经处理了你不要再往外抛返回False或None表示异常继续向上传播。用一个极简的自定义对象来演示class ManagedFile: def __init__(self, name): self.name name def __enter__(self): print(进入 with 代码块) self.file open(self.name, w) return self.file def __exit__(self, exc_type, exc_val, exc_tb): print(退出 with 代码块) if self.file: self.file.close() return False with ManagedFile(demo.txt) as f: f.write(hello)运行这段代码会看到先打印进入再打印退出。如果把f.write改成抛异常依然会打印退出因为无论代码块内发生了什么__exit__都会被调用。这就是with最核心的价值保证退出动作一定会执行。2.2 with 语句的完整执行流程与三种例外情况with的执行流程可以拆成四步计算with后面的表达式得到上下文管理器对象例如执行open(...)得到一个文件对象文件对象本身就是上下文管理器。调用对象的__enter__()把返回值赋值给as后的变量。如果不用as返回值被丢弃但__enter__依然会被调用。执行with代码块主体。无论主体是否抛出异常调用__exit__(exc_type, exc_val, exc_tb)。第 4 步有几种分支情况很多人第一次看容易绕晕我整理成了一张速查表场景__exit__接收的参数__exit__返回 True__exit__返回 False/None代码块正常结束(None, None, None)正常结束无异常正常结束无异常代码块抛异常异常的 type/value/traceback异常被吞掉代码块后的代码继续执行异常继续向上抛出__enter__本身抛异常不调用__exit__无无有一种例外情况值得单独强调如果异常发生在__enter__方法内部__exit__不会被执行因为对象根本没有成功进入。这其实很好理解就像你进商场刷卡了但闸机坏了你还没进到商场里面商场自然不会负责送你出门。另一种情况是__exit__自己抛了异常那么这个新异常会替代原来的异常继续向外传播。所以别在__exit__里写可能出错的清理逻辑而不做内部保护。参考 Python 官方文档对with语句语义的说明用try/finally来模拟with是最直观的manager open(demo.txt, w) var manager.__enter__() try: var.write(hello) finally: manager.__exit__(None, None, None)当然这是简化模型实际的异常参数传递比这个复杂但理解到这层已经够用。3. 三种实现上下文管理器的主流方案3.1 基于类实现把__enter__/__exit__写清楚最传统、也最容易理解的方式是定义一个类实现两个魔法方法。适合需要保存状态、需要精细管理资源的场景。class Timer: def __enter__(self): import time self.start time.perf_counter() return self def __exit__(self, exc_type, exc_val, exc_tb): self.elapsed time.perf_counter() - self.start print(f耗时 {self.elapsed:.6f} 秒) return False使用时with Timer(): sum(range(1000000))类方式的好处是清晰、可复用、可以在__init__里收参数。缺点是样板代码稍多每个上下文管理器都要写四个方法__init__、__enter__、__exit__、通常还有别的。如果你只是临时想测一段代码的执行时间完全没必要专门造一个类。类方式还有一个常见用途把__enter__返回值设计成自己方便在with代码块里访问上下文属性。上面例子就是这样with Timer() as t:之后t就是Timer实例本身代码块里可以随时访问t.start。3.2 基于contextlib.contextmanager与yield更短的代码Python 的contextlib模块提供了一个装饰器contextmanager让你不用写类也能生成上下文管理器。核心逻辑是用一个生成器函数配合yield切分进入和退出yield之前的代码对应__enter__yield语句本身把返回值交给as变量yield之后的代码对应__exit__from contextlib import contextmanager contextmanager def managed_file(name): f open(name, w) try: yield f finally: f.close() with managed_file(demo.txt) as f: f.write(hello)注意看yield被try/finally包裹。这个finally很重要它保证即使with代码块里抛了异常f.close()也会执行。用contextmanager装饰时yield后面的代码实际上会被包装进__exit__的逻辑里如果yield之前初始化失败后面代码不会执行这与类实现的__enter__抛异常不调用__exit__一致。contextmanager的写法简洁很多特别适合一次性的、小型的上下文管理需求。我自己在项目里大部分场景都用它只有需要复杂状态时才会回到类实现。3.3 标准库自带的高频上下文管理器Python 标准库里面已经内置了大量上下文管理器拿过来就能用不需要自己实现。最常被用到的是open()返回的文件对象。第二个高频货是threading.Lockimport threading lock threading.Lock() # 传统写法 lock.acquire() try: # 临界区 pass finally: lock.release() # with 写法 with lock: # 临界区 passcontextlib.closing也很有用。有些资源对象自带close()但没有实现上下文管理器协议比如一个自定义的网络客户端。closing包装后就可以用with管理from contextlib import closing class SomeClient: def close(self): print(资源关闭) def query(self): return data with closing(SomeClient()) as client: print(client.query())标准库还有一个contextlib.redirect_stdout我调试时经常用它把 print 输出重定向到文件或字符串import io from contextlib import redirect_stdout buf io.StringIO() with redirect_stdout(buf): print(这段内容会写入缓冲区) output buf.getvalue()contextlib.suppress也很香。它专门用来吞掉指定的异常比try/except: pass更直观from contextlib import suppress with suppress(FileNotFoundError): os.remove(nope.txt)如果nope.txt不存在suppress会把它吞掉程序不报错。这个用法在清理临时文件时非常省心。4. 实操案例把上下文管理器用进真实项目4.1 计时器一个能反复用的性能检测工具先说一个最简单的实用案例。我在做接口性能优化时经常要测一小段逻辑的耗时。传统写法是手动记录两个时间点然后相减。有了contextmanager可以做成一个可以反复用的计时器import time from contextlib import contextmanager contextmanager def timeit(labelelapsed): start time.perf_counter() try: yield finally: elapsed time.perf_counter() - start print(f{label}: {elapsed:.4f}s) with timeit(查询订单): orders query_orders()这段代码的核心在于time.perf_counter()。它比time.time()精度更高特别适合测量短耗时操作。finally里的打印保证了即使代码块中途异常退出耗时也能显示出来方便我们定位到底是哪次异常导致性能问题。4.2 数据库事务与连接管理把 commit/rollback 写进上下文数据库操作是上下文管理器的重头戏。一个连接从获取、执行 SQL、到提交或回滚、最后归还连接整个生命周期串下来中间任何一环出错都会造成数据不一致或连接泄漏。我习惯把连接获取 事务控制一起封装from contextlib import contextmanager import pymysql contextmanager def db_transaction(conn_config): conn pymysql.connect(**conn_config) try: yield conn conn.commit() # 代码块正常结束提交事务 except Exception: conn.rollback() # 代码块抛异常回滚事务 raise # 异常继续抛给上层 finally: conn.close() # 无论是否异常连接都要归还 with db_transaction(MY_CONFIG) as conn: with conn.cursor() as cursor: cursor.execute(UPDATE account SET balance balance - 100 WHERE id 1) cursor.execute(UPDATE account SET balance balance 100 WHERE id 2)这里有几个细节值得注意。第一conn.cursor()本身也是上下文管理器所以可以嵌套with。第二yield返回的是连接对象上层代码拿到它直接执行 SQL。第三commit()写在yield之后意味着只有代码块没有异常才会提交一旦有异常会走except分支回滚。第四raise不能省否则异常被吞上层无法感知失败。这个模式囊括了事务的 ACID 特性非常实用。4.3 临时切换环境目录、环境变量与 PATH有时候你需要临时修改进程的全局状态比如切换工作目录。手动切换的痛点是容易忘记切回来。os.chdir()切换后如果代码报错后续代码还运行在原目录的假设下定位问题极其痛苦。用上下文管理器可以自动还原import os from contextlib import contextmanager contextmanager def working_directory(path): cwd os.getcwd() os.chdir(path) try: yield finally: os.chdir(cwd) with working_directory(/tmp): # 当前目录是 /tmp pass # 退出后自动回到原来的目录同理临时修改环境变量、临时追加PYTHONPATH都可以用这个模式。关键点是先把旧值保存下来yield之后再恢复。finally保证即使代码块异常环境也不会被污染。这一类上下文管理器在写测试、跑数据迁移脚本时特别好用。4.4 嵌套 with 与管理多个资源ExitStack 的优雅解法实际项目中经常要同时打开多个资源。初学者喜欢一层套一层with open(a.txt) as fa: with open(b.txt) as fb: pass层次浅还好资源一多就变成金字塔代码很不雅观。Python 3.10 之前相同层级的资源可以写在同一行用逗号分隔with open(a.txt) as fa, open(b.txt) as fb: pass但如果资源的数量是动态的比如一个列表里有 10 个文件要同时打开就不能静态写在with里了。这时候要上contextlib.ExitStackfrom contextlib import ExitStack file_paths [a.txt, b.txt, c.txt] with ExitStack() as stack: files [stack.enter_context(open(path)) for path in file_paths] # 这里的 files 是三个文件对象全部可用 # 退出 with 块时三个文件按后进先出顺序自动关闭ExitStack的原理是动态注册退出回调。你可以注册任意数量的上下文管理器在with块结束时按栈的顺序统一清理。它尤其适合在函数里收集各种资源再统一释放的场景。我写测试框架时经常用ExitStack临时 push 一堆 mock 对象退出代码块自动全部撤销比手写 try/finally 干净得多。5. 常见问题与排查技巧实录5.1__exit__返回值为什么容易被忽略最常见的坑是你以为__exit__里的异常处理生效了但实际上它return True把异常吞了上层完全不知道失败。来看这个例子class IgnoreAll: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): print(exit called) return True with IgnoreAll(): raise ValueError(something wrong) print(程序继续执行)这段代码会打印exit called再打印程序继续执行异常完全被吞。在某些场景下这是故意为之但更多时候是意外的——比如你在__exit__里写了return self本意是返回对象但__exit__的返回值会被当作布尔值处理self非空即True结果异常被吞掉排查问题找半天找不到原因。我的建议是除非明确知道自己在做什么否则__exit__都应该return False或return None让异常继续往外抛。如果真想吞掉至少加一行注释说明意图。5.2 生成器实现的上下文管理器抛异常后怎么办使用contextmanager时yield之间的代码如果抛异常要明白异常会直接传到调用方。但有个容易踩的细节如果yield之后的清理代码抛了异常这个异常会替代原始异常掩盖真正的问题。举个例子contextmanager def buggy(): try: yield finally: 1 / 0 # 清理代码本身出错 with buggy(): raise ValueError(原始异常)在这个场景中调用方看到的是ZeroDivisionError而不是原始的ValueError。清理代码抛出的异常会覆盖业务代码的异常。解决办法是清理逻辑也要包一层防护至少记录下来原始异常。我在做资源清理时会先在except里保存异常信息清理代码尽量只做简单操作防止误伤。5.3 不要用with open读大文件的一个误区很多人觉得with open(big.txt) as f:能自动管理资源就放心地data f.read()。但对好几 GB 的大文件一次性read()会直接把内存打爆。with负责的是文件句柄的释放不负责内存的管控。大文件应该逐行或分块读取with open(big.txt) as f: for line in f: process(line)如果必须一次性读取部分块可以用f.read(1024 * 1024)循环读。另外注意with只保证文件对象生命周期结束并不等于全部内容都安全内存问题要根据数据量单独设计。5.4 上下文管理器与装饰器的搭配contextmanager 的边界contextmanager不但能装饰普通生成器函数还能与装饰器结合实现装饰器 上下文的双重能力。一个常见的组合是在装饰器里包裹上下文from functools import wraps from contextlib import contextmanager contextmanager def log_errors(): try: yield except Exception as e: print(f捕获异常: {e}) raise def logged(func): wraps(func) def wrapper(*args, **kwargs): with log_errors(): return func(*args, **kwargs) return wrapper这里logged装饰器把函数调用包在上下文管理器里。好处是逻辑复用日志逻辑和业务逻辑解耦。但注意不要滥用contextmanager装饰的生成器函数一旦yield之后抛出异常该异常同样会传播给调用方所以装饰器里如果再包一层try/except就要小心异常的层级关系。5.5 上下文管理器别忘了处理as变量作用域with open(a) as f:里的f在退出with块后依然存在但它指向的文件对象已经关闭。很多人误以为出了with块变量就没了其实 Python 根本没有块级作用域。这意味着退出后如果误用了f会得到ValueError: I/O operation on closed file。我建议在with块结束后立即置空或者明确不再使用该变量。如果需要在with块外面继续保留数据把数据复制到普通变量里不要让资源对象逃逸出去。这个细节在写复杂函数时很容易引发隐蔽 bug。6. 实战收尾我的经验与习惯写上下文管理器这几年我个人最常用的其实是contextmanagerExitStack的组合。contextmanager负责把繁琐的清理逻辑压缩成几行代码ExitStack负责管理数量不定的资源两者配合几乎能覆盖我遇到的所有场景。类实现虽然规范但大多数业务里用不上那么重的抽象。还有一个很多人不知道的小技巧contextlib里有个ContextDecorator可以让你的上下文管理器直接当装饰器用。如果你设计的with块本身没有对外部状态的依赖那么把__enter__和__exit__写到类里并继承ContextDecorator同一个类既能用于with也能用于装饰函数一鱼两吃。最后说一个实际的体会上下文管理器最忌讳的是做太多。它本质上是资源的守卫不是业务逻辑的容器。我见过有人把整个接口的业务逻辑全塞进一个巨大的with块说这样自动回收所有资源。这种写法会让代码极难阅读而且一旦__exit__里动作过多任何一个清理错误都会拉垮整个调用链。保持__enter__精简、__exit__稳定、yield之间的代码短小才是真正用好上下文管理器的秘诀。希望这篇整理对你有用下次写资源相关代码时多想想with帮你挡住了哪些坑。