1. 为什么需要上下文管理器先告别手写资源释放我见过不少刚入门 Python 的同学写文件操作是这样的f open(data.txt, r) data f.read() f.close()这段代码看起来很合理但用不了多久就会踩坑。比如读取文件时抛出了异常f.close()根本没机会执行文件句柄就一直开着。更隐蔽的问题是如果data.txt不存在open本身就会抛异常但很多初学者会在已经打开文件之后又做了一些别的操作导致异常最后文件没关程序内存里的文件描述符越积越多。这在 Windows 上表现尤其明显——你可能莫名其妙地发现文件被占用删不掉改不了重启程序又好了。后来大家开始写try/finallyf open(data.txt, r) try: data f.read() finally: f.close()这样确实把“无论有没有异常都要关闭文件”这件事表达出来了但问题也随之而来每操作一个资源都要写一遍 try/finally代码会变得很啰嗦。而且如果你想同时操作多个资源就得嵌套写try/finally代码缩进越来越深可读性断崖式下跌。这里有一个很生活化的类比。上下文管理器就像是租了一辆共享单车正规流程不是“付完钱骑走就行”而是你用完要把车停好、锁好才算完成一次完整的操作。如果不锁车后台会一直扣费你可能自己都不知道。Python 里的资源文件、数据库连接、锁也这样你用完了不“归还”系统就会一直帮你记着这笔账直到程序退出才统一释放。上下文管理器做的就是替你把这个“归还”的动作变成自动的——只要你写好协议Python 就保证在代码块结束之后替你处理善后。而with语句就是触发上下文管理器协议的入口。它的核心价值一句话就能说清把资源和资源的生命周期绑定到一起让资源随用随开、用完即关而且无论代码块里发生了什么都能可靠地完成善后。这篇文章我打算从原理到实践讲透这个话题。你会看到__enter__和__exit__的实际执行顺序、异常在 with 语句里是怎么流转的、contextlib模块里几个偷懒神器怎么用以及我在真实项目中封装数据库事务、锁和多资源管理时踩过的一些坑。2. 协议层面的真相__enter__和__exit__如何协作2.1 一个最小实现足以说明问题先看一个最简单的自定义上下文管理器class MyResource: def __enter__(self): print(进入 with 块开始占用资源) return self def __exit__(self, exc_type, exc_val, exc_tb): print(离开 with 块资源已释放) return False with MyResource() as res: print(在 with 块内部做事情)运行这段代码你会看到进入 with 块开始占用资源 在 with 块内部做事情 离开 with 块资源已释放就这么简单。with做的事情本质上是调用MyResource()得到实例对象准确的说是调用MyResource.__enter__()把返回值赋给as后面的变量。执行with代码块里的语句。无论代码块正常结束还是抛出异常都调用实例的__exit__()方法。这里有一个容易搞混的点as后面的变量到底是什么它不一定是类实例本身而是__enter__的返回值。如果__enter__返回self那变量就是这个对象如果__enter__返回别的变量就是别的。比如你写了一个数据库连接上下文管理器完全可以在__enter__里返回一个游标对象让下面的代码直接操作游标。2.2 为什么设计成两个方法而不是一个很多人第一次接触时觉得__enter__/__exit__有点绕心想“搞一个__del__或者统一的release方法不就行了”我当时的理解是__enter__负责“准备阶段”__exit__负责“善后阶段”两者分离的价值在于 with 代码块运行之前和之后的控制权都交给了类自己。举个例子。数据库连接的场景__enter__里可以完成连接、开启事务__exit__里可以根据代码块是否异常决定事务是提交还是回滚。如果只有一个释放方法你就没法在“资源归还”时拿到“代码块是否正常”这个关键信息。__exit__的参数设计正是为这个服务的。2.3 也许你误解了__exit__的返回值__exit__接收四个参数exc_type异常类型、exc_val异常实例、exc_tbtraceback 对象。当 with 块没有异常时这三个参数都是None。当 with 块抛出异常时Python 会把异常信息传进__exit__。关键点来了__exit__返回的布尔值决定了异常是不是要继续向上抛出。返回True告诉 Python “异常我已经处理了你别往上抛了”程序会继续往后执行。返回False或返回None因为None本身为假异常继续向上传播最终可能打断程序。看这个例子class SuppressEverything: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): print(捕获到异常, exc_val) return True with SuppressEverything(): 1 / 0 print(程序还活着)输出会是捕获到异常 division by zero 程序还活着因为__exit__返回了True除以零的异常被吞掉了。这个返回值非常容易被忽略。如果你在自定义上下文管理器时想“透传”异常就必须返回False或者干脆不写 return默认返回None。2.4 字节码视角with 到底干了什么想深入验证 Python 对 with 的处理可以借助dis模块看字节码。拿一个最简单的函数来开刀import dis def demo(): with open(a.txt) as f: return f.read() dis.dis(demo)你会看到字节码里有几个关键指令CALL_FUNCTION初始化对象然后调用__enter__用STORE_FAST把返回值赋给f块结束时调用__exit__。也就是说编译器在生成字节码的层面就把整个流程安排成“先调用进去方法块结束无论如何调用退出方法”。这也解释了为什么 with 语句比手写 try/finally 更可靠——编译器都帮你编排好了你只需要关注业务代码。3. 运行时顺序与异常传播退出方法里你该做什么3.1 正常路径下的三步走当 with 块内部没有异常时执行顺序非常清晰执行__enter__拿到资源或相关对象。执行 with 块主体代码。调用__exit__传入的exc_type、exc_val、exc_tb都是None。在这个路径里__exit__主要做“收尾”关闭文件、释放锁、提交或回滚事务等。3.2 异常路径下的处理决策当 with 块内部抛出异常时__exit__是唯一能够在异常终结程序之前“插手”的地方。我之前做网络爬虫时经常用这个特性实现“某次请求失败后稍微等一下再重试”的逻辑。核心思路是把重试机制封装在上下文管理器里业务代码只需写一次请求逻辑。import time class Retry: def __init__(self, times3, wait1): self.times times self.wait wait self.attempt 0 def __enter__(self): self.attempt 1 return self def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is None: return False self.attempt 1 if self.attempt self.times: print(f第 {self.attempt} 次失败等待 {self.wait} 秒后重试) time.sleep(self.wait) return True # 吞掉当前异常让外层重新进入 with 块 return False # 重试次数用完让异常正常抛出 for _ in range(1): with Retry(times3, wait1): import random if random.random() 0.5: raise ValueError(模拟失败)但需要注意的是__exit__返回True吞掉异常有一个副作用你无法在和 with 同级的代码里直接捕获到被吞掉的异常。如果你希望外层能看到异常的详细信息就不能轻易返回True要么重新抛出要么把异常信息记录到上下文管理器状态里供外部查看。3.3 常见误区在__exit__里做异常掩盖我在代码评审时见过这样的写法class Connection: def __exit__(self, exc_type, exc_val, exc_tb): # 想记录日志结果不小心把异常吞了 if exc_type: print(Error occurred:, exc_val) return True这类代码最直接的后果就是调用了你的Connection上下文管理器的代码即使内部出现严重异常外层也完全感知不到。线上排查问题时你会发现日志打出了错误信息但程序坚称一切都好异常根本不会继续抛。所以我的习惯是除非明确要“吞异常”否则__exit__一律不写return True甚至不写 return。如果要在退出时记录日志记录完让异常继续往上抛。4. 偷懒的正确姿势contextlib避免样板代码只用类实现上下文管理器确实还是略显繁琐。你需要定义类、写两个方法还要注意__init__里的参数传递。contextlib模块提供了很多便捷方式这也是我日常项目里使用频率最高的一个模块。4.1contextmanager用生成器写上下文管理器最经典的是contextmanager装饰器。它的用法很反直觉但理解之后会觉得巧妙极了from contextlib import contextmanager contextmanager def temp_file(name): print(创建临时文件, name) yield name # 这一个 yield 把函数分成两段 print(清理临时文件, name) with temp_file(test.txt) as f: print(使用文件, f)输出创建临时文件 test.txt 使用文件 test.txt 清理临时文件 test.txt这个写法的核心逻辑是yield之前的代码相当于__enter__yield之后的代码相当于__exit__。但这里有个隐性问题——如果 with 块里抛出了异常异常会被抛回生成器内部并出现在yield那一行。这意味着你需要显式用try/finally包住yield才能保证清理代码一定会执行。写的时候最好这样contextmanager def temp_file(name): print(创建临时文件, name) try: yield name finally: print(清理临时文件, name)虽然常见的示例代码里不写try/finally也能跑但一旦 with 块抛异常你的清理代码就不会执行。深刻理解后我建议你每次都加上try/finally这是一种成本极低但极其可靠的习惯。4.2ExitStack动态管理一堆资源ExitStack是我最喜欢的工具没有之一。它解决的痛点是一段代码里需要打开多个资源但数量不确定或者要根据条件决定要不要打开某个资源。from contextlib import ExitStack with ExitStack() as stack: files [] for filename in [a.txt, b.txt, c.txt]: f open(filename) stack.enter_context(f) # 把文件的管理权交给 ExitStack files.append(f) # 循环结束、with 块退出时所有文件都会按相反顺序关闭你也可以用stack.callback注册一个普通的清理函数比如stack.callback(print, 进程结束关闭连接)。ExitStack 最爽的一点是它能在进入阶段出现异常时自动关闭已经成功进入的上下文管理器而不是让它们泄漏。4.3suppress和closing两个高频小工具contextlib.suppress用来预期某段代码可能会发生特定异常并且你想忽略它。比如删除一个可能不存在的临时文件from contextlib import suppress import os with suppress(FileNotFoundError): os.remove(temp.dat)这比try/except: pass更简洁语义也更明确。不过要提醒的是suppress只适合你真的想忽略异常的场合如果异常代表系统性问题你应当让它浮出来。closing适合那些只有close()方法、但没有实现上下文管理协议的对象from contextlib import closing with closing(some_connection()) as conn: # 用 conn 做点什么 # 退出后自动调用 conn.close()这在处理某些第三方库返回的句柄比如urllib.request.urlopen返回的对象时很实用。5. 实战我把上下文管理器用在哪些真实场景5.1 文件读取最经典但远不是唯一文件操作是 with 最常出现的地方因为文件句柄属于操作系统的有限资源忘记关闭的后果在长时间运行的服务里会被放大。文件对象自身已经实现了上下文管理器协议你只需要直接写with open(log.txt, r, encodingutf-8) as f: lines f.readlines()如果文件读取过程中出现异常文件也会关闭这是 with 提供的保险。5.2 数据库事务提交还是回滚写一次就够了在我做 Web 后端开发的经历里数据库事务是上下文管理器最能发挥价值的地方之一。让我回想一个典型的场景你有一个函数向数据库插入订单表和订单明细表两步之间随便哪一步失败前面的写入都应该回滚否则数据库会留下半截脏数据。手写时你可以用try/except控制commit还是rollback但每个函数都写一遍就太麻烦了。更优雅的方案是封装一个事务上下文管理器import sqlite3 class DatabaseTransaction: def __init__(self, connection): self.conn connection def __enter__(self): # sqlite 默认不开事务这里手动开启 self.conn.execute(BEGIN) return self.conn def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is None: self.conn.commit() else: self.conn.rollback() return False # 异常继续往外抛使用起来很简单conn sqlite3.connect(shop.db) with DatabaseTransaction(conn) as cursor: cursor.execute(INSERT INTO orders (id, amount) VALUES (1, 99.0)) cursor.execute(INSERT INTO order_items (order_id, item_id) VALUES (1, 10))第二步如果失败第一步的数据会自动回滚数据库不会处于“上一条成功了下一条断了”的状态。封装一次到处复用这是我项目里价值最高的上下文管理器之一。需要注意一个细节sqlite3里commit和rollback的调用时机以及有些数据库驱动默认开启自动提交。你在设计自己的事务上下文管理器时必须先弄清楚底层驱动的默认行为否则事务边界可能是假的。5.3 多资源嵌套锁和临时文件一起管理在一个多线程程序中你可能同时需要“加锁 操作临时文件”。如果手写嵌套代码很容易缩进地狱lock threading.Lock() with lock: with open(tmp.txt, w) as f: f.write(hello)虽然这样写没错但嵌套超过三层就会很难看。这里可以用表达式组合的方式避免嵌套from contextlib import ExitStack with ExitStack() as stack: stack.enter_context(lock) # 加锁 f stack.enter_context(open(tmp.txt, w)) # 打开文件 f.write(hello)在项目里处理复杂资源时这个写法能显著提升代码可读性。我的习惯是只要涉及的资源超过两个就优先想ExitStack而不是多层缩进。5.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:.4f} 秒) with timer(解析配置文件): # do something time.sleep(0.5)这种用法让代码里的性能测量点非常轻量你不会为了测一段代码耗时而大改结构。同理你也可以给代码块注入“当前请求 ID”之类的日志上下文让整个处理链路的日志统一带追踪 ID。6. 进阶玩法与需要注意的几个坑6.1 异步版本async with与__aenter__、__aexit__现在异步编程越来越多Python 也给 with 出了异步版本。协议名称从__enter__/__exit__变成了__aenter__/__aexit__关键字从with变成了async with。import asyncio class AsyncConnection: async def __aenter__(self): print(异步连接建立) return self async def __aexit__(self, exc_type, exc_val, exc_tb): print(异步连接关闭) return False async def main(): async with AsyncConnection() as conn: print(使用异步连接) asyncio.run(main())注意两点一是异步版本必须在协程函数里使用二是如果继续用contextlib应该用asynccontextmanager装饰器而不是contextmanager。from contextlib import asynccontextmanager asynccontextmanager async def get_conn(): conn await create_connection() try: yield conn finally: await conn.close()我在写异步爬虫和异步数据库访问代码时async with几乎成了标配因为它能保证 IO 资源在异步代码里的生命周期可靠闭合不会因为某个await抛异常就漏掉关闭动作。6.2 千万不要在__exit__里做耗时操作我踩过一个比较典型的坑在__exit__里调用了一个可能阻塞好几秒的网络请求。当时想做“退出时把状态上报到监控系统”结果那段不需要的同步上报让关键路径的延迟大幅上升且如果在上报脚本里出现异常还会影响原业务逻辑。所以我的经验是__exit__只应该做“快而稳”的清理动作。耗时的上报、网络调用、大批量数据落库尽量不要放进__exit__宁可让调用方显式控制也不要让每次 with 结束都背上额外开销。6.3 上下文管理器也要注意异常掩盖的连锁反应前面提到__exit__返回True会吞掉异常还有一个连锁反应如果__exit__里在异常发生时自己又抛了一个异常Python 会直接用新异常替换旧异常。这两个异常都不会丢但新异常的 traceback 里会带上旧异常的上下文通过__context__关联。排查问题的时候你会看到一堆“During handling of the above exception, another exception occurred”的日志处理起来很累。所以在__exit__里写清理逻辑时尽量给清理代码也包上 try/except防止清理异常掩盖主体异常。6.4 上下文管理器的作用域与小陷阱with 块内部创建的变量在 Python 里属于函数作用域不会因为 with 块结束就消失with open(data.txt) as f: content f.read() print(content) # 可以正常打印但f在块外已经关闭了。这个行为常让初学者困惑——变量还在资源没了。你如果把变量名冲到外层作用域就有可能在之后不小心操作一个已经关闭的资源。我的建议是尽量缩小变量的使用范围只在 with 块内使用f避免后面代码误用。6.5 生成器式上下文管理器的 yield 分割语义用contextmanager写上下文管理器时有个隐含的规则需要特别注意装饰器内部的生成器只能 yield 一次。如果你在一个上下文管理器里写了两个 yield到 with 块退出时Python 会因为生成器执行不正常而报错。写之前要想清楚yield 前面的代码是“进入时做的事”yield 后面的代码是“退出时做的事”中间不需要夹别的 yield。我自己还踩过一个坑在 yield 之前放了一个return结果 with 进入时直接返回了根本没有把资源交出去但生成器没有异常程序表现得很“正常”——直到资源没被正确持有后面的代码才开始报错。这类问题排查起来特别费神所以背诵一条经验装饰器函数里yield 是必经之路不要随意提前 return。7. 我的一些个人体会上下文管理器是我在 Python 里最喜欢的一个特性之一。它不像装饰器那样需要反复琢磨函数封装也不像元类那样涉及复杂的类型系统但它能非常自然地改变代码的组织方式。写文件、加锁、开事务、管连接这些日常操作在有了上下文管理器之后从“我得记得小心释放资源”变成了“代码块结束资源自然归还”心智负担小了很多。如果你刚开始接触我的建议是先把手里的try/finally改成 with 试试体会一下代码变短的快感。然后可以试着把你重复用到的资源管理逻辑封装成自己的上下文管理器数据库事务是个不错的练手项目。最后再看看 contextlib 里那些现成的小工具你也会发现很多代码的写法立马变得干净利落。有一个很简单的判断标准只要一段代码明显存在“开始”和“结束”两个动作并且结束动作必须在任何情况下都执行都值得用上下文管理器封装。包括但不限于文件、连接、锁、计时、状态切换、进度条展示甚至环境变量临时修改。一旦形成这个判断习惯你会发现自己的代码里到处都是可以封装成上下文管理器的机会写出来的代码也明显更易读、更不容易漏掉关键操作了。 
长河君 · 2026/10/7 17:02:41 · 阅读 1.2k Python上下文管理器深度实战：从with原理到contextlib技巧
1. 为什么需要上下文管理器先告别手写资源释放我见过不少刚入门 Python 的同学写文件操作是这样的f open(data.txt, r) data f.read() f.close()这段代码看起来很合理但用不了多久就会踩坑。比如读取文件时抛出了异常f.close()根本没机会执行文件句柄就一直开着。更隐蔽的问题是如果data.txt不存在open本身就会抛异常但很多初学者会在已经打开文件之后又做了一些别的操作导致异常最后文件没关程序内存里的文件描述符越积越多。这在 Windows 上表现尤其明显——你可能莫名其妙地发现文件被占用删不掉改不了重启程序又好了。后来大家开始写try/finallyf open(data.txt, r) try: data f.read() finally: f.close()这样确实把“无论有没有异常都要关闭文件”这件事表达出来了但问题也随之而来每操作一个资源都要写一遍 try/finally代码会变得很啰嗦。而且如果你想同时操作多个资源就得嵌套写try/finally代码缩进越来越深可读性断崖式下跌。这里有一个很生活化的类比。上下文管理器就像是租了一辆共享单车正规流程不是“付完钱骑走就行”而是你用完要把车停好、锁好才算完成一次完整的操作。如果不锁车后台会一直扣费你可能自己都不知道。Python 里的资源文件、数据库连接、锁也这样你用完了不“归还”系统就会一直帮你记着这笔账直到程序退出才统一释放。上下文管理器做的就是替你把这个“归还”的动作变成自动的——只要你写好协议Python 就保证在代码块结束之后替你处理善后。而with语句就是触发上下文管理器协议的入口。它的核心价值一句话就能说清把资源和资源的生命周期绑定到一起让资源随用随开、用完即关而且无论代码块里发生了什么都能可靠地完成善后。这篇文章我打算从原理到实践讲透这个话题。你会看到__enter__和__exit__的实际执行顺序、异常在 with 语句里是怎么流转的、contextlib模块里几个偷懒神器怎么用以及我在真实项目中封装数据库事务、锁和多资源管理时踩过的一些坑。2. 协议层面的真相__enter__和__exit__如何协作2.1 一个最小实现足以说明问题先看一个最简单的自定义上下文管理器class MyResource: def __enter__(self): print(进入 with 块开始占用资源) return self def __exit__(self, exc_type, exc_val, exc_tb): print(离开 with 块资源已释放) return False with MyResource() as res: print(在 with 块内部做事情)运行这段代码你会看到进入 with 块开始占用资源 在 with 块内部做事情 离开 with 块资源已释放就这么简单。with做的事情本质上是调用MyResource()得到实例对象准确的说是调用MyResource.__enter__()把返回值赋给as后面的变量。执行with代码块里的语句。无论代码块正常结束还是抛出异常都调用实例的__exit__()方法。这里有一个容易搞混的点as后面的变量到底是什么它不一定是类实例本身而是__enter__的返回值。如果__enter__返回self那变量就是这个对象如果__enter__返回别的变量就是别的。比如你写了一个数据库连接上下文管理器完全可以在__enter__里返回一个游标对象让下面的代码直接操作游标。2.2 为什么设计成两个方法而不是一个很多人第一次接触时觉得__enter__/__exit__有点绕心想“搞一个__del__或者统一的release方法不就行了”我当时的理解是__enter__负责“准备阶段”__exit__负责“善后阶段”两者分离的价值在于 with 代码块运行之前和之后的控制权都交给了类自己。举个例子。数据库连接的场景__enter__里可以完成连接、开启事务__exit__里可以根据代码块是否异常决定事务是提交还是回滚。如果只有一个释放方法你就没法在“资源归还”时拿到“代码块是否正常”这个关键信息。__exit__的参数设计正是为这个服务的。2.3 也许你误解了__exit__的返回值__exit__接收四个参数exc_type异常类型、exc_val异常实例、exc_tbtraceback 对象。当 with 块没有异常时这三个参数都是None。当 with 块抛出异常时Python 会把异常信息传进__exit__。关键点来了__exit__返回的布尔值决定了异常是不是要继续向上抛出。返回True告诉 Python “异常我已经处理了你别往上抛了”程序会继续往后执行。返回False或返回None因为None本身为假异常继续向上传播最终可能打断程序。看这个例子class SuppressEverything: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): print(捕获到异常, exc_val) return True with SuppressEverything(): 1 / 0 print(程序还活着)输出会是捕获到异常 division by zero 程序还活着因为__exit__返回了True除以零的异常被吞掉了。这个返回值非常容易被忽略。如果你在自定义上下文管理器时想“透传”异常就必须返回False或者干脆不写 return默认返回None。2.4 字节码视角with 到底干了什么想深入验证 Python 对 with 的处理可以借助dis模块看字节码。拿一个最简单的函数来开刀import dis def demo(): with open(a.txt) as f: return f.read() dis.dis(demo)你会看到字节码里有几个关键指令CALL_FUNCTION初始化对象然后调用__enter__用STORE_FAST把返回值赋给f块结束时调用__exit__。也就是说编译器在生成字节码的层面就把整个流程安排成“先调用进去方法块结束无论如何调用退出方法”。这也解释了为什么 with 语句比手写 try/finally 更可靠——编译器都帮你编排好了你只需要关注业务代码。3. 运行时顺序与异常传播退出方法里你该做什么3.1 正常路径下的三步走当 with 块内部没有异常时执行顺序非常清晰执行__enter__拿到资源或相关对象。执行 with 块主体代码。调用__exit__传入的exc_type、exc_val、exc_tb都是None。在这个路径里__exit__主要做“收尾”关闭文件、释放锁、提交或回滚事务等。3.2 异常路径下的处理决策当 with 块内部抛出异常时__exit__是唯一能够在异常终结程序之前“插手”的地方。我之前做网络爬虫时经常用这个特性实现“某次请求失败后稍微等一下再重试”的逻辑。核心思路是把重试机制封装在上下文管理器里业务代码只需写一次请求逻辑。import time class Retry: def __init__(self, times3, wait1): self.times times self.wait wait self.attempt 0 def __enter__(self): self.attempt 1 return self def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is None: return False self.attempt 1 if self.attempt self.times: print(f第 {self.attempt} 次失败等待 {self.wait} 秒后重试) time.sleep(self.wait) return True # 吞掉当前异常让外层重新进入 with 块 return False # 重试次数用完让异常正常抛出 for _ in range(1): with Retry(times3, wait1): import random if random.random() 0.5: raise ValueError(模拟失败)但需要注意的是__exit__返回True吞掉异常有一个副作用你无法在和 with 同级的代码里直接捕获到被吞掉的异常。如果你希望外层能看到异常的详细信息就不能轻易返回True要么重新抛出要么把异常信息记录到上下文管理器状态里供外部查看。3.3 常见误区在__exit__里做异常掩盖我在代码评审时见过这样的写法class Connection: def __exit__(self, exc_type, exc_val, exc_tb): # 想记录日志结果不小心把异常吞了 if exc_type: print(Error occurred:, exc_val) return True这类代码最直接的后果就是调用了你的Connection上下文管理器的代码即使内部出现严重异常外层也完全感知不到。线上排查问题时你会发现日志打出了错误信息但程序坚称一切都好异常根本不会继续抛。所以我的习惯是除非明确要“吞异常”否则__exit__一律不写return True甚至不写 return。如果要在退出时记录日志记录完让异常继续往上抛。4. 偷懒的正确姿势contextlib避免样板代码只用类实现上下文管理器确实还是略显繁琐。你需要定义类、写两个方法还要注意__init__里的参数传递。contextlib模块提供了很多便捷方式这也是我日常项目里使用频率最高的一个模块。4.1contextmanager用生成器写上下文管理器最经典的是contextmanager装饰器。它的用法很反直觉但理解之后会觉得巧妙极了from contextlib import contextmanager contextmanager def temp_file(name): print(创建临时文件, name) yield name # 这一个 yield 把函数分成两段 print(清理临时文件, name) with temp_file(test.txt) as f: print(使用文件, f)输出创建临时文件 test.txt 使用文件 test.txt 清理临时文件 test.txt这个写法的核心逻辑是yield之前的代码相当于__enter__yield之后的代码相当于__exit__。但这里有个隐性问题——如果 with 块里抛出了异常异常会被抛回生成器内部并出现在yield那一行。这意味着你需要显式用try/finally包住yield才能保证清理代码一定会执行。写的时候最好这样contextmanager def temp_file(name): print(创建临时文件, name) try: yield name finally: print(清理临时文件, name)虽然常见的示例代码里不写try/finally也能跑但一旦 with 块抛异常你的清理代码就不会执行。深刻理解后我建议你每次都加上try/finally这是一种成本极低但极其可靠的习惯。4.2ExitStack动态管理一堆资源ExitStack是我最喜欢的工具没有之一。它解决的痛点是一段代码里需要打开多个资源但数量不确定或者要根据条件决定要不要打开某个资源。from contextlib import ExitStack with ExitStack() as stack: files [] for filename in [a.txt, b.txt, c.txt]: f open(filename) stack.enter_context(f) # 把文件的管理权交给 ExitStack files.append(f) # 循环结束、with 块退出时所有文件都会按相反顺序关闭你也可以用stack.callback注册一个普通的清理函数比如stack.callback(print, 进程结束关闭连接)。ExitStack 最爽的一点是它能在进入阶段出现异常时自动关闭已经成功进入的上下文管理器而不是让它们泄漏。4.3suppress和closing两个高频小工具contextlib.suppress用来预期某段代码可能会发生特定异常并且你想忽略它。比如删除一个可能不存在的临时文件from contextlib import suppress import os with suppress(FileNotFoundError): os.remove(temp.dat)这比try/except: pass更简洁语义也更明确。不过要提醒的是suppress只适合你真的想忽略异常的场合如果异常代表系统性问题你应当让它浮出来。closing适合那些只有close()方法、但没有实现上下文管理协议的对象from contextlib import closing with closing(some_connection()) as conn: # 用 conn 做点什么 # 退出后自动调用 conn.close()这在处理某些第三方库返回的句柄比如urllib.request.urlopen返回的对象时很实用。5. 实战我把上下文管理器用在哪些真实场景5.1 文件读取最经典但远不是唯一文件操作是 with 最常出现的地方因为文件句柄属于操作系统的有限资源忘记关闭的后果在长时间运行的服务里会被放大。文件对象自身已经实现了上下文管理器协议你只需要直接写with open(log.txt, r, encodingutf-8) as f: lines f.readlines()如果文件读取过程中出现异常文件也会关闭这是 with 提供的保险。5.2 数据库事务提交还是回滚写一次就够了在我做 Web 后端开发的经历里数据库事务是上下文管理器最能发挥价值的地方之一。让我回想一个典型的场景你有一个函数向数据库插入订单表和订单明细表两步之间随便哪一步失败前面的写入都应该回滚否则数据库会留下半截脏数据。手写时你可以用try/except控制commit还是rollback但每个函数都写一遍就太麻烦了。更优雅的方案是封装一个事务上下文管理器import sqlite3 class DatabaseTransaction: def __init__(self, connection): self.conn connection def __enter__(self): # sqlite 默认不开事务这里手动开启 self.conn.execute(BEGIN) return self.conn def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is None: self.conn.commit() else: self.conn.rollback() return False # 异常继续往外抛使用起来很简单conn sqlite3.connect(shop.db) with DatabaseTransaction(conn) as cursor: cursor.execute(INSERT INTO orders (id, amount) VALUES (1, 99.0)) cursor.execute(INSERT INTO order_items (order_id, item_id) VALUES (1, 10))第二步如果失败第一步的数据会自动回滚数据库不会处于“上一条成功了下一条断了”的状态。封装一次到处复用这是我项目里价值最高的上下文管理器之一。需要注意一个细节sqlite3里commit和rollback的调用时机以及有些数据库驱动默认开启自动提交。你在设计自己的事务上下文管理器时必须先弄清楚底层驱动的默认行为否则事务边界可能是假的。5.3 多资源嵌套锁和临时文件一起管理在一个多线程程序中你可能同时需要“加锁 操作临时文件”。如果手写嵌套代码很容易缩进地狱lock threading.Lock() with lock: with open(tmp.txt, w) as f: f.write(hello)虽然这样写没错但嵌套超过三层就会很难看。这里可以用表达式组合的方式避免嵌套from contextlib import ExitStack with ExitStack() as stack: stack.enter_context(lock) # 加锁 f stack.enter_context(open(tmp.txt, w)) # 打开文件 f.write(hello)在项目里处理复杂资源时这个写法能显著提升代码可读性。我的习惯是只要涉及的资源超过两个就优先想ExitStack而不是多层缩进。5.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:.4f} 秒) with timer(解析配置文件): # do something time.sleep(0.5)这种用法让代码里的性能测量点非常轻量你不会为了测一段代码耗时而大改结构。同理你也可以给代码块注入“当前请求 ID”之类的日志上下文让整个处理链路的日志统一带追踪 ID。6. 进阶玩法与需要注意的几个坑6.1 异步版本async with与__aenter__、__aexit__现在异步编程越来越多Python 也给 with 出了异步版本。协议名称从__enter__/__exit__变成了__aenter__/__aexit__关键字从with变成了async with。import asyncio class AsyncConnection: async def __aenter__(self): print(异步连接建立) return self async def __aexit__(self, exc_type, exc_val, exc_tb): print(异步连接关闭) return False async def main(): async with AsyncConnection() as conn: print(使用异步连接) asyncio.run(main())注意两点一是异步版本必须在协程函数里使用二是如果继续用contextlib应该用asynccontextmanager装饰器而不是contextmanager。from contextlib import asynccontextmanager asynccontextmanager async def get_conn(): conn await create_connection() try: yield conn finally: await conn.close()我在写异步爬虫和异步数据库访问代码时async with几乎成了标配因为它能保证 IO 资源在异步代码里的生命周期可靠闭合不会因为某个await抛异常就漏掉关闭动作。6.2 千万不要在__exit__里做耗时操作我踩过一个比较典型的坑在__exit__里调用了一个可能阻塞好几秒的网络请求。当时想做“退出时把状态上报到监控系统”结果那段不需要的同步上报让关键路径的延迟大幅上升且如果在上报脚本里出现异常还会影响原业务逻辑。所以我的经验是__exit__只应该做“快而稳”的清理动作。耗时的上报、网络调用、大批量数据落库尽量不要放进__exit__宁可让调用方显式控制也不要让每次 with 结束都背上额外开销。6.3 上下文管理器也要注意异常掩盖的连锁反应前面提到__exit__返回True会吞掉异常还有一个连锁反应如果__exit__里在异常发生时自己又抛了一个异常Python 会直接用新异常替换旧异常。这两个异常都不会丢但新异常的 traceback 里会带上旧异常的上下文通过__context__关联。排查问题的时候你会看到一堆“During handling of the above exception, another exception occurred”的日志处理起来很累。所以在__exit__里写清理逻辑时尽量给清理代码也包上 try/except防止清理异常掩盖主体异常。6.4 上下文管理器的作用域与小陷阱with 块内部创建的变量在 Python 里属于函数作用域不会因为 with 块结束就消失with open(data.txt) as f: content f.read() print(content) # 可以正常打印但f在块外已经关闭了。这个行为常让初学者困惑——变量还在资源没了。你如果把变量名冲到外层作用域就有可能在之后不小心操作一个已经关闭的资源。我的建议是尽量缩小变量的使用范围只在 with 块内使用f避免后面代码误用。6.5 生成器式上下文管理器的 yield 分割语义用contextmanager写上下文管理器时有个隐含的规则需要特别注意装饰器内部的生成器只能 yield 一次。如果你在一个上下文管理器里写了两个 yield到 with 块退出时Python 会因为生成器执行不正常而报错。写之前要想清楚yield 前面的代码是“进入时做的事”yield 后面的代码是“退出时做的事”中间不需要夹别的 yield。我自己还踩过一个坑在 yield 之前放了一个return结果 with 进入时直接返回了根本没有把资源交出去但生成器没有异常程序表现得很“正常”——直到资源没被正确持有后面的代码才开始报错。这类问题排查起来特别费神所以背诵一条经验装饰器函数里yield 是必经之路不要随意提前 return。7. 我的一些个人体会上下文管理器是我在 Python 里最喜欢的一个特性之一。它不像装饰器那样需要反复琢磨函数封装也不像元类那样涉及复杂的类型系统但它能非常自然地改变代码的组织方式。写文件、加锁、开事务、管连接这些日常操作在有了上下文管理器之后从“我得记得小心释放资源”变成了“代码块结束资源自然归还”心智负担小了很多。如果你刚开始接触我的建议是先把手里的try/finally改成 with 试试体会一下代码变短的快感。然后可以试着把你重复用到的资源管理逻辑封装成自己的上下文管理器数据库事务是个不错的练手项目。最后再看看 contextlib 里那些现成的小工具你也会发现很多代码的写法立马变得干净利落。有一个很简单的判断标准只要一段代码明显存在“开始”和“结束”两个动作并且结束动作必须在任何情况下都执行都值得用上下文管理器封装。包括但不限于文件、连接、锁、计时、状态切换、进度条展示甚至环境变量临时修改。一旦形成这个判断习惯你会发现自己的代码里到处都是可以封装成上下文管理器的机会写出来的代码也明显更易读、更不容易漏掉关键操作了。