开头不是那种直接进入正题无所谓。先讲一件我实际遇到过的事。有一回线上服务突然内存和句柄数同时报警进程撑了不到半小时就被系统强制杀掉。排查到最后定位到一段从老代码里继承下来的逻辑某个自定义客户端类里手动open()了连接却在多个分支上漏掉了close()。后来我把它改写成with句式问题再没出现过。从那次之后我对 Python 上下文管理器with 语句的看法就变了——它不只是省几行代码的语法糖而是一种把“资源生命周期”焊死在程序流程里的能力。这篇文章会把with从底层执行过程到常见实现方式、再到实战落点完整拆一遍适合已经写过一段时间 Python、想彻底搞清楚它的读者。1. 底层协议with 在执行时到底做了哪几件事1.1 一次完整的 with 调用在解释器里被展开成四步很多人写with open(a.txt) as f:但并不知道 Python 究竟对它做了什么。其实with语句背后依赖两个协议方法__enter__和__exit__。只要一个对象实现了这两个方法它就能被with接管。可以看下面这段简化后的展开逻辑它基本还原了 CPython 解释器的处理过程mgr EXPR # 1. 先计算 EXPR得到上下文管理器对象 exit type(mgr).__exit__ # 2. 拿到 __exit__ 方法注意是 type 上的不是实例上的 value type(mgr).__enter__(mgr) # 3. 调用 __enter__结果绑定给 as 后面的变量 try: VAR value with_block() # 4. 执行 with 代码块 except Exception: if not exit(mgr, *sys.exc_info()): raise else: exit(mgr, None, None, None)这个展开逻辑里有两个容易被忽略的点。第一__enter__和__exit__是通过type(mgr)拿到的也就是说它走的是真正的类型方法查找如果你在实例上动态绑一个__enter__函数with是认不出来的。第二代码块正常执行完__exit__收到的是三个None代码块抛出异常__exit__收到的是异常类型、异常对象和 traceback 三件套。无论哪种情况__exit__都会被调用这就是with能兜底的根基。1.2 异常发生时exit收到的东西长什么样我建议初学者做一次这样的实验自己写一个最简上下文管理器终止块里故意抛一个异常看看__exit__里能拿到什么。class TraceCM: def __enter__(self): print(enter) return self def __exit__(self, exc_type, exc_val, exc_tb): print(exit called:) print( exc_type:, exc_type) print( exc_val :, exc_val) print( exc_tb :, exc_tb) return False # 表示不吞掉异常 with TraceCM(): raise ValueError(boom)输出会是这样enter exit called: exc_type: class ValueError exc_val : boom exc_tb : traceback object at 0x...然后异常继续向上抛程序崩溃。这个实验让人直观地看到无论with块内部发生什么退出逻辑都会执行。__enter__只管“进场”__exit__负责“退场”而且退场是有保障的。还要说清楚一个边界with能保证的是“在正常 Python 控制流里一定会调用__exit__”包括return、break、continue、异常这些情况但如果进程被os._exit()强杀、或者操作系统直接 kill 掉进程__exit__是来不及执行的。不要把with神话成“任何情况都会清理”它只是把我们能控制的那部分控制流全部接管了。2.exit的返回值异常是被吞掉还是继续抛2.1 返回 True 意味着你主动吞掉了异常__exit__的返回值只有True和False或者等价于这两个值的对象有意义。False或None表示“我不处理这个异常让它继续往外抛”True表示“我已经处理了解释器不要再把它抛出”。一个稍微冷门但很有价值的用法是允许上下文管理器选择性地抑制某些异常。比如你想让某个块内的EOFError被静默掉但其它异常必须正常上抛就可以写成这样class suppress_eof: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): return exc_type is EOFError with suppress_eof(): raise EOFError(can be silent) print(到这里了EOFError 被吞掉)这种写法的问题也在于“吞掉”这件事太容易误用。只要返回True异常链就断了。调试的时候最恐怖的就是某个任务在队列里抛了异常结果异常被某个写得很随意的上下文管理器吃掉任务永远不在错误日志里出现整个系统看起来“一切正常”实际上数据早就错位了。我自己在代码评审里看到return True会格外警惕除非我能明确说出“吞掉哪类异常、为什么可以吞、吞掉之后的语义是什么”否则一律要求改成return False。2.2 数据库连接里被误解的 with conn它管的是事务不是关闭连接Python 的sqlite3模块里Connection对象实现了上下文管理器协议很多人下意识以为with conn:会自动关闭连接。实际不是它管理的是事务代码块正常结束就commit()抛出异常就rollback()连接本身需要你手动close()。import sqlite3 conn sqlite3.connect(demo.db) try: with conn: conn.execute(INSERT INTO users(name) VALUES(?), (Alice,)) # 正常走到这里事务已提交 except sqlite3.IntegrityError: # 想象一下如果上面某条 SQL 抛了异常with 已自动 rollback pass finally: conn.close()在with conn:块里写入多条 SQL就能体会到事务语义的便利要么全部成功提交要么全部回滚。但这里有个大坑不同数据库驱动的行为并不一致。有的连接的__exit__里默认commit有的默认close有的什么都不做。最稳妥的办法是用某个第三方库之前直接去读它的源码或文档里对__enter__/__exit__的实现说明千万别靠猜。2.3 想显式抑制异常时优先用 contextlib.suppress如果你就是想让某段代码“对某类异常无感”更推荐用contextlib.suppress它比手写try / except ... pass更短而且不容易误伤from contextlib import suppress import os with suppress(FileNotFoundError): os.remove(not-exist.txt) # 文件不存在也不会报错suppress要求你显式列出需要忽略的异常类型所以它不会像return True那样把未知异常也吞掉。这个工具适合清理场景比如删除临时文件、关闭不存在的锁文件等。原则很简单抑制异常的范围一定要越小越好宁可精确到某个具体异常类型也不要图省事写BaseException。3. 三种实现方式怎么选类、contextmanager、ExitStack3.1 类实现状态复杂或需要区分异常类型时的第一选择最正统的写法是定义一个类实现__enter__和__exit__。当你的上下文管理器需要持有多个状态、需要在__enter__和__exit__之间传递数据、或者要根据异常类型做不同处理时类是最合适的。一个我经常用的例子临时修改环境变量用完立刻恢复原值。这个需求在测试和运行子进程时很常见。import os class env_var: def __init__(self, name, value): self.name name self.value value self.old None def __enter__(self): self.old os.environ.get(self.name) os.environ[self.name] self.value return self def __exit__(self, exc_type, exc_val, exc_tb): if self.old is None: os.environ.pop(self.name, None) else: os.environ[self.name] self.old return False # 异常照常抛不掺和 with env_var(PYTHONHASHSEED, 42): print(os.environ[PYTHONHASHSEED]) print(os.environ.get(PYTHONHASHSEED)) # 已被恢复类实现的优点是可以把状态存在self上__exit__里能拿到__enter__设置过的旧值。缺点是要多写一些样板代码。如果你的场景就是“进入时做 A退出时做 B”不需要保存太多状态那用生成器版更轻快。3.2 contextmanager 生成器版最省代码但清理必须放进 finallycontextlib.contextmanager可以把一个生成器函数改造成上下文管理器。yield之前的代码在__enter__时执行yield本身把值交给as变量yield之后的代码在__exit__时执行。from contextlib import contextmanager contextmanager def managed_file(path, moder): f open(path, mode) try: yield f finally: f.close()用的时候很简单with managed_file(hello.txt) as f: print(f.read())这里有一个新手很容易写错的版本只写yield f然后直接f.close()不包try/finally。这样如果with块内部抛了异常异常会在yield处重新抛出f.close()根本来不及执行。所以用生成器实现上下文管理器时清理逻辑一定要放在finally块里或者用try/except包住yield以便拿到异常参数。这个细节我不止一次在代码评审里看到翻车。生成器版还适合写“计时器”这类只需要进入和退出动作的场景后面实战部分我会再演示。3.3 ExitStack资源数量和顺序无法预知时的解药ExitStack是contextlib里非常强大的工具它允许你动态地向一个栈里压入任意多个上下文管理器然后在这个with块退出时按后进先出的顺序统一清理。比如你有个函数要根据配置项列表打开 N 个文件每个文件都必须在函数结束时关掉from contextlib import ExitStack def read_first_lines(paths): with ExitStack() as stack: files [stack.enter_context(open(path)) for path in paths] return [f.readline().strip() for f in files]files这个列表里的每个文件都是由ExitStack在退出时统一关闭的。即使中间某个open失败了前面已经打开的那些文件也会被逐个清理不会泄漏句柄。ExitStack还有一个很实用的方法pop_all()把当前栈里的清理回调原封不动地转移到另一个栈也就是“资源所有权转移”。什么时候用当你的函数需要把一批临时文件的生命周期延长到外部作用域时可以在with ExitStack()内部构建好然后stack.pop_all()把责任交出去。def build_bundle(): with ExitStack() as stack: f1 stack.enter_context(open(a.txt)) f2 stack.enter_context(open(b.txt)) return stack.pop_all()这样调用方拿到ExitStack对象后可以继续with它来管理这些文件的关闭时机。这个玩法在框架代码里很常见普通业务代码用得不多但值得知道因为它能解决“数量不定、动态扩展”的场景。3.4 顺手盘点 contextlib 里值得记忆的小工具redirect_stdout/redirect_stderr临时把标准输出/错误重定向到文件对象测试断言时很好用。nullcontext不开任何资源的占位上下文管理器常配合可选参数的场景。ContextDecorator让上下文管理器可以当作装饰器用减少重复缩进。这些工具不复杂但能在合适的地方大幅简化代码。比如nullcontext在函数参数里可以让调用方决定某个操作是否启用上下文管理器from contextlib import nullcontext def process(use_timerTrue): cm timer(process) if use_timer else nullcontext() with cm: do_work()把“要不要管理资源”从业务逻辑里解耦出来代码会显得干净不少。4. 实战把锁、事务和临时目录全部交给 with4.1 线程锁with lock 天然避免死锁threading.Lock、RLock、Semaphore这些同步原语本身就实现了上下文管理器协议所以你可以直接import threading lock threading.Lock() counter 0 def worker(): global counter for _ in range(1000): with lock: temp counter temp 1 counter temp这段代码如果换成手写acquire/release最容易出问题的点就是中途return忘了release导致其它线程永久阻塞。而with lock把释放动作绑定到了代码块退出无论是正常结束还是异常退出锁都会在__exit__里被释放这是防死锁最便宜的姿势。有个细节需要注意Lock的__enter__不接受超时参数。如果你想用acquire(timeout...)做“拿不到锁就跳过”的逻辑with lock是做不到的。这种情况要么老老实实写try/finally要么自己封装一个支持超时的上下文管理器。这个区别我在面试里问过不少人能答出来的基本都是真正写过并发代码的。4.2 数据库事务封装一个 transaction 上下文管理器数据库连接的事务管理是很适合封装成上下文管理器的典型场景。以sqlite3之外的 MySQL 驱动为例手动写commit/rollback很容易漏掉某个分支。用一个生成器版上下文管理器把事务流程收敛起来from contextlib import contextmanager contextmanager def transaction(conn): try: yield except Exception: conn.rollback() raise else: conn.commit()用法with transaction(conn): update_stock(conn, product_id, delta) insert_order(conn, order_no)这里把commit放在else而不是finally里是有讲究的finally无论有无异常都会执行而else只在try块没有异常时执行正好符合“没异常才提交”的语义。rollback之后还要raise让上层调用者能看到失败原因而不是把错误吞掉。如果业务代码里可能有SystemExit或KeyboardInterrupt注意except Exception是接不住的。是否需要把这些写成except BaseException取决于你的实际场景——一般连接池的清理逻辑放在最外层finally里兜底事务本身只处理Exception就够了不必为了极端情况牺牲代码可读性。4.3 临时文件系统一次 with 自动清理tempfile.TemporaryDirectory和NamedTemporaryFile都支持上下文管理器协议测试和数据处理脚本里非常实用。import tempfile from pathlib import Path with tempfile.TemporaryDirectory(prefixmydata-) as tmpdir: target Path(tmpdir) / result.bin target.write_bytes(bsome bytes) # 在这里做业务处理 # 目录里的文件在退出时会被整体删除使用这个模式后你再也不用担心测试跑完留下一堆垃圾目录。配合ExitStack还能在一个with块里同时管理多个临时目录with ExitStack() as stack: dirs [stack.enter_context(tempfile.TemporaryDirectory()) for _ in range(3)] # 三个临时目录统一回收有一个必须注意的坑如果with块里把临时文件的路径交给了别的线程或子进程并且那个线程在块退出之后才去读取文件文件已经没了。with的语义是“退出即清理”所以需要“延长生命周期”时不要硬用上下文管理器改为mkdtemp()生成目录然后手动清理或者用weakref.finalize注册兜底清理逻辑。4.4 给性能调优做个计时器有时候你只想知道“这一段代码跑了多久”用装饰器会连函数调用开销都算进去而上下文管理器能把计时范围精确到一个代码块import time from contextlib import contextmanager contextmanager def timer(name): start time.perf_counter() try: yield finally: elapsed time.perf_counter() - start print(f{name}: {elapsed * 1000:.1f} ms)使用with timer(parse): parse_file(data.json) with timer(train): model.fit(X, y)这个写法最大的价值是“边界可视化”——读代码的人一眼就能看出你想量哪段逻辑。加try/finally是为了防止被计时的代码抛异常时计时器不输出结果虽然程序要崩溃了但至少能留下一个耗时记录排查性能问题时很有用。5. 边界情况与异步return 不会绕过退出async with 是另一套协议5.1 return / break / continue也会触发exit很多人觉得with块里一旦return后面的代码就没有了清理逻辑自然也不会执行。事实恰恰相反return、break、continue都算“退出代码块”__exit__都会被调用。class CM: def __enter__(self): print(enter) return self def __exit__(self, *args): print(exit, args:, args[:1]) return False def choose(flag): with CM(): if flag: return 42 return 0 choose(True) # 输出 # enter # exit, args: (class NoneType,) # 实际上正常退出三个参数都是 None这个特性让with在“提前退出”的业务分支里特别安心不需要在每一个return前面手动加清理代码。当然前面也说过进程崩溃这类极端情况除外。5.2 as 绑定的是enter的返回值不是上下文管理器本身with obj as x:里的x并非一定是obj它绑定的是obj.__enter__()的返回值。如果__enter__返回self那x才是对象本身如果它返回别的x就是别的东西。class CursorProvider: def __enter__(self): return self.create_cursor() # 返回的甚至不是实例本身 def create_cursor(self): return {cursor_id: 42}这点在阅读第三方库代码时常遇到。比如某些数据库驱动里with conn:拿到的不是连接对象而是事务游标如果库的__enter__写的是return self那as拿到的是连接。实践中踩坑最多的就是“以为as后面的对象就是表达式的结果对象”结果对象不支持某些方法跑起来才报AttributeError。5.3 多个上下文管理器一行写多个退出顺序是后进先出with A() as a, B() as b:等同于嵌套的with A() as a:再进入with B() as b:退出时先B后A后进先出。with open(a.txt) as fa, open(b.txt) as fb: # 正常处理两个文件Python 3.10 以后还允许多行括号写法代码更易读with ( open(a.txt) as fa, open(b.txt) as fb, ): ...这个顺序在资源有层次关系时很重要。比如外层是数据库事务内层是保存点退出时肯定要先释放内层保存点再回滚或提交外层事务所以 LIFO 的语义正好符合直觉。5.4 async with异步资源也有自己的协议从 Python 3.5 开始异步代码可以使用async with对应协议是__aenter__和__aexit__。同步的with无法混用异步对象同理async with也必须写在协程函数里。最常见的例子是asyncio.Lockimport asyncio async def main(): lock asyncio.Lock() async with lock: async def critical(): ... await critical()aiohttp、asyncpg这些异步库的会话和连接池也都实现了异步上下文管理器用法和同步版几乎一样只是把with改成async with。这里要提示一个容易踩的点异步任务被取消时__aexit__通常会执行但如果你挂在某个await上一直没有返回取消信号也不一定能及时让清理逻辑跑完。所以异步资源管理比同步要复杂必要时得配合asyncio.shield保护关键操作。另一个实用工具是contextlib.aclosing()它专门用来安全关闭异步生成器避免直接在async with里裸aclose()时吞掉StopAsyncIteration异常。5.5 把“退出即失效”装进大脑最后分享一点我自己的习惯。我现在看代码只要发现“手动 open 之后必须记得 close”“手动 acquire 之后必须记得 release”这种配套逻辑就会条件反射地想要一个上下文管理器。这不仅是代码风格问题更是可靠性问题——人一定会忘而协议不会。即使是临时脚本如果生命周期稍微复杂一点我也倾向写成with因为以后重跑这个脚本时你会感激当时那个多写了两行的自己。回头再想那次线上事故其实根因并不复杂就是资源管理没有任何强制机制兜底。而with的整套设计——无论代码块是正常结束、异常退出、还是提前return__exit__都会被执行——恰恰补上了这块。真正理解了它之后很多并发、IO、数据库相关的代码写起来会踏实很多。希望这篇分享对你有用。