如果你写过一阵子Python肯定见过这种写法with open(data.txt, r) as f: data f.read()大多数教程告诉你这样写能自动关闭文件不用手动f.close()。但你把with换成try/finally之后是不是真的等价为什么有的对象能跟with配合有的却报AttributeErroras拿到的到底是什么退出with代码块时如果中间抛了异常那个异常到底是被谁接住了这篇文章不打算停在“with就是自动关资源”这种层面。我会把上下文管理器context manager的协议机制、实现方式、踩坑点一次性讲透然后给出一批可以直接拿去用的实践案例。适合已经会用with open()但还没系统搞懂原理的人也适合想自己写上下文管理器来封装业务逻辑的同学。1. 先搞清楚with语句解决的从来不只是“关闭文件”很多人把上下文管理器理解成“自动清理资源”这其实只是它的效果之一不是全部。要真正理解with得先回到它要解决的问题本身代码块需要一种可靠的前置准备和后置清理机制。你想想日常写代码里有多少这种场景改一个全局配置用完要还原拿了一个锁用完要释放开了一个事务提交失败要回滚切了一个工作目录结束要切回去。这些行为有一个共同点——无论中间代码执行成功还是抛异常后置动作都必须执行。1.1 没有with的原始时代代码长什么样在没有上下文管理器之前大家最常写的是try/finallyf open(data.txt, r) try: data f.read() process(data) finally: f.close()这段代码问题不大但它有三个隐患open本身可能抛异常如果open失败f根本不存在finally里的f.close()会再抛一个NameError把原始异常盖掉容易漏写finally块尤其是业务代码一多你很容易记得打开忘了关闭try和finally之间的距离太远代码一长读者需要反复回看才知道这段代码在保障什么。Python社区显然受够了这种写法所以搞出了with语句。它不是简单地把try/finally封装起来而是定义了一套“可复用的协议”——任何类只要实现了这套协议就能享受统一的、可靠的进入与退出机制。1.2 为什么叫“上下文管理器”而不叫“资源管理器”这是个特别容易被忽略但实际上很关键的问题。如果with只是用来关文件它应该叫资源管理器才更贴切。但官方把它命名为“上下文管理器”是因为它管理的范围比“资源”大得多。with块里的代码在执行时处于一种”被特别安排过的环境“中——也许是临时改了一个环境变量也许是拿到了某个事务的边界也许是设置了一次临时的日志级别。这个环境就是“上下文”context。上下文管理器要做的事情是你进入这个环境时我帮你搭好一切你离开时无论过程如何我帮你还原一切。比如我想临时切换工作目录然后保证离开代码块后目录自动还原import os from contextlib import contextmanager contextmanager def switch_directory(path): old_dir os.getcwd() os.chdir(path) try: yield finally: os.chdir(old_dir) with switch_directory(/tmp): print(os.getcwd()) # /tmp print(os.getcwd()) # 已经还原注意这里没有任何“资源”需要关闭但它照样是标准的上下文管理器用法。理解了这一点你对with的认知就升级了它不只是“自动关文件”的语法糖而是一个通用的、可组合的“环境进入/退出契约”。2. 底层协议拆解__enter__和__exit__是怎么协同工作的现在进入正题。一个对象要支持with语句必须实现两个魔法方法__enter__和__exit__。这构成了Python里的“上下文管理协议”。2.1 with语句的完整执行序列当你写下with expr as var:时Python解释器实际干的事情是这样的计算expr表达式得到上下文管理器对象context manager调用该对象的__enter__()方法把__enter__()的返回值绑定到as后面的变量var上执行with代码块里的语句代码块结束或抛出异常后调用该对象的__exit__()方法。注意as var是可选的。如果省略as var那第二步的返回值会被丢弃但__enter__仍然会被调用。这也是很多老手都会忽略的细节——你就算不写as上下文管理器该准备的东西一样会准备。以下面这个最小实现为例class DemoContext: def __enter__(self): print(进入上下文) return 42 def __exit__(self, exc_type, exc_val, exc_tb): print(退出上下文) return False with DemoContext() as value: print(value , value) # 输出 # 进入上下文 # value 42 # 退出上下文有个很常见的误区是以为as后面的变量就是with后面的对象本身。其实不一定。as拿到的值是__enter__()的返回值。大多数时候比如open()的__enter__返回self所以看起来像是对象本身但如果你自己写上下文管理器__enter__完全可以返回另一个东西。2.2 退出时的三个关键参数__exit__是上下文管理器的核心难点因为它要同时处理“正常退出”和“异常退出”两条路径。它的完整签名是def __exit__(self, exc_type, exc_val, exc_tb): ...这三个参数分别是exc_type异常类比如ValueError。如果你不需要这个信息写_占位即可exc_val异常实例即raise后面的那个异常对象exc_tbtraceback对象包含堆栈信息。调试时很有用。注意一个关键点当with代码块正常结束、没有抛异常时这三个参数全部为None你的__exit__依然会被调用这时候你在__exit__里要做的只有清理工作不要误以为“有异常才会调用__exit__”。这个方法的返回值直接决定异常传播的走向返回False或不写return默认返回None如果代码块抛了异常异常会继续向外传播返回True如果代码块抛了异常这个异常会被吞掉从外部看起来代码块“没出问题”。我强烈建议你默认返回False或干脆不写返回值除非你明确知道自己要吞掉异常。下面写一个带异常感知的示例class ExceptionRecorder: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is not None: print(f捕获到异常: {exc_type.__name__}: {exc_val}) # 只记录不吞掉继续向上抛 return False try: with ExceptionRecorder(): raise RuntimeError(出错了) except RuntimeError as e: print(外层收到异常:, e)实际输出会是两行一行打印“捕获到异常”一行打印“外层收到异常”。这说明__exit__看到了异常但选择了放行。这个模式特别适合做“带日志的资源清理器”。2.3 __enter__的返回值想给什么就给什么__enter__可以返回任意对象。这个设计非常灵活实际中的典型做法有几种文件对象返回自身open()就是这么干的因为后续读写操作都依赖这个对象数据库连接返回游标cursor因为进入with块后你最常用的是游标而不是连接本身锁对象返回自身方便链式调用自定义对象返回一个内部的临时句柄。我自己实现数据库访问时很喜欢让__enter__返回一个新的游标对象代码如下class DatabaseConnection: def __init__(self, conn): self.conn conn def __enter__(self): self.cursor self.conn.cursor() return self.cursor def __exit__(self, exc_type, exc_val, exc_tb): if self.cursor: # 关闭游标 self.cursor.close() # 连接本身通常不在这里关连接属于更上层的生命周期 return False这样写的好处是as cur拿到的就是游标你少写一行conn.cursor()。代码的语义也更清晰——进入这个上下文就是“去数据库上执行一次操作”的环境。3. 手写一个带异常感知的数据库会话说了一堆原理下面来点实的。我以数据库会话为例写一个完整可用的上下文管理器。它要解决这几个问题进入with时自动获取一个连接或游标代码块正常结束时自动提交事务代码块抛出异常时自动回滚事务无论什么情况都保证游标/连接被关闭。3.1 用class实现一个数据库事务会话这里我用sqlite3演示换成psycopg2、pymysql逻辑完全一样import sqlite3 class DatabaseSession: def __init__(self, db_path): self.db_path db_path self.conn None def __enter__(self): self.conn sqlite3.connect(self.db_path) # 开启显式事务 self.conn.execute(BEGIN) return self.conn def __exit__(self, exc_type, exc_val, exc_tb): if self.conn is None: return False try: if exc_type is None: # 没有异常提交 self.conn.commit() else: # 有异常回滚 self.conn.rollback() finally: self.conn.close() return False # 异常继续抛给外层使用方式with DatabaseSession(test.db) as conn: conn.execute(INSERT INTO user(name) VALUES (张三))这段代码如果INSERT执行成功退出时自动commit如果INSERT抛异常退出时自动rollback然后异常继续上抛。实现原理不难核心就两点__exit__里通过exc_type is None判断代码块是否正常结束用finally保证连接一定被关闭不会因为commit本身出错而漏关。这里的BEGIN是sqlite3里开启事务的SQL语句其它数据库可能有细微差异但思想一致。如果你用的是Django、SQLAlchemy这种ORM它们内部已经封装了类似机制但你理解了原理后使用起来会更心里有底。3.2 用contextlib.contextmanager写一套轻量级实现如果不想写完整的类contextlib.contextmanager装饰器会让代码量减少一半。它的原理是把生成器函数改造成上下文管理器yield之前的部分对应__enter__yield之后的部分对应__exit__yield本身传出的值会绑定到as后面的变量。from contextlib import contextmanager contextmanager def db_session(db_path): conn sqlite3.connect(db_path) conn.execute(BEGIN) try: yield conn # 正常执行结束后到这里提交 conn.commit() except: # 有异常就回滚 conn.rollback() raise finally: conn.close()用法完全一样with db_session(test.db) as conn: conn.execute(INSERT INTO user(name) VALUES (李四))对比一下就会发现contextmanager写法比class写法更贴近“叙事逻辑”先写“进入时要做什么”然后yield交控制权给with代码块代码块正常执行完继续执行yield后面的代码——这里通常放“正常收尾”逻辑如果代码块抛异常这个异常会在yield处重新抛出所以你用except接住做回滚再raise把它抛出去。这里有个重要细节yield之前的代码如果没有用try包住那么进入阶段一旦出错后面的清理代码同样不会执行。所以严谨写法应该把整个流程包进try/finally我上面的代码还显式加了except用来处理提交/回滚分支。3.3 两种实现怎么选我个人的选择标准是逻辑简单、只有进入和退出两段动作时优先用contextmanager代码短、好读需要在退出时访问大量内部状态、或者被很多地方复用且需要继承扩展时用class实现更合适如果你的上下文管理器只是临时用一次直接用contextmanager写个函数即可不要为了“规范”强行造类。4. 实际工作中最容易翻车的四个场景与排查思路原理看完了代码也写了接下来聊聊实战。这部分全是实打实踩过的坑每一个都曾经让我调试到怀疑人生。4.1 __exit__返回True就是吞掉异常别顺手写了True这个坑我真的见得太多了。很多初学者为了让代码“不报错”在__exit__里写return True然后发现外部怎么捕获都捕获不到异常。因为异常已经在__exit__返回True的那一刻被解释器判定为“已处理”了。经典的翻车现场class IgnoreEverything: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): # 这里本想记录日志但误写成返回True return True try: with IgnoreEverything(): raise ValueError(这条错误会被吞掉) except ValueError: print(永远不会执行到这里)排查思路当你发现“有异常但外面抓不到”时第一反应就应该是检查__exit__的返回值。如果你确实需要吞异常也要非常明确地只吞指定类型的异常不要无脑返回True。如果你只是想“忽略某一种异常”标准库contextlib.suppress已经帮你做好了from contextlib import suppress with suppress(FileNotFoundError): os.remove(not_exist.txt)这个用法我强烈推荐比自己写__exit__返回True安全得多。4.2 数据库连接关闭不等于事务提交这个坑坑过很多熟人。你以为with conn:结束后数据就稳稳写进数据库了不一定。看这段代码import sqlite3 conn sqlite3.connect(test.db) with conn: conn.execute(INSERT INTO user(name) VALUES (王五)) # 这里你以为已经提交了sqlite3连接对象本身支持上下文管理协议with conn:退出时会提交事务或回滚事务然后关闭连接吗查一下文档你会发现sqlite3连接的__exit__确实会提交/回滚但没有显式关闭连接。而很多其它数据库驱动比如psycopg2with conn:只负责提交/回滚也不负责关闭连接。所以不要想当然地把“连接对象的上下文管理”等同于“关闭连接”。如果你期望退出with后连接也关闭就要自己封装就像我在第3节里写的DatabaseSession那样在__exit__里显式close()。另外还有一个反向的坑如果你只调用了conn.close()而没有先commit()那么连接关闭时未提交的事务会被回滚。这是一条“静默丢数据”的路径非常危险。我自己的习惯是数据库操作一律显式写commit不依赖上下文管理器的隐式提交除非我完全清楚这个驱动的__exit__行为。4.3 contextmanager装饰的生成器函数yield之后抛异常后续清理代码不会执行这个坑在写contextmanager时最容易踩。看下面的例子from contextlib import contextmanager contextmanager def safe_operation(): print(前置准备) yield print(后置清理) with safe_operation(): raise RuntimeError(中间出错)输出是什么只有“前置准备”不会打印“后置清理”。原因在于当with代码块抛异常时这个异常会从yield那个位置抛出于是yield之后的代码根本不会执行除非你把它包在try/finally里。这就是为什么严谨的做法是contextmanager def safe_operation(): print(前置准备) try: yield finally: # 这里无论有没有异常都会执行 print(后置清理)无论是写上下文管理器还是用生成器做资源管理只要涉及“必须清理”的动作一律放进finally。这条规则能避免90%以上莫名其妙的资源残留问题。4.4 with后面跟多个对象时执行顺序和退出顺序是反的从Python 2.7和3.1开始with后面可以跟多个上下文管理器with open(a.txt) as f1, open(b.txt) as f2: ...执行顺序是f1先进、f2后进退出顺序恰好相反f2先退出、f1后退出。这和栈的结构一致后进先出。少有人注意到的是Python 3.10之后支持了带括号的写法with ( open(a.txt) as f1, open(b.txt) as f2, ): pass这个写法在上下文管理器很多、一行写不下时非常有用但注意as f1前面的逗号不能丢。退出顺序和普通写法一样仍然是后进先出。多上下文管理器的常见坑如果前一个对象的__exit__返回了True它会吞掉异常导致后续对象的__exit__根本不会被调用。因为异常一旦被吞掉with语句认为“没出错”就不会再去触发嵌套上下文的异常退出逻辑。这个行为在依赖多个资源联动的场景下很容易让人困惑调试时务必检查每个__exit__返回值。5. 上下文管理器的高阶用法把它当成业务逻辑的“边界契约”前面讲的都是“用现有API包一层”。上下文管理器更高级的用法是把它当作业务边界的显式声明。5.1 用上下文管理器实现临时修改配置再自动还原之前提到过切换目录的例子。同样的逻辑还能用来临时改环境变量这在测试和生产排障时特别有用import os from contextlib import contextmanager contextmanager def override_environ(key, value): old_value os.environ.get(key) os.environ[key] value try: yield finally: if old_value is None: os.environ.pop(key, None) else: os.environ[key] old_value with override_environ(DEBUG, 1): print(os.environ[DEBUG]) # 1 print(os.environ.get(DEBUG)) # None这段代码虽然简单但用到了上下文管理器最核心的价值保证环境一定被还原。以后你写测试时想临时模拟“DEBUG开/关”两种状态再也不用自己手写try和finally了。5.2 用ExitStack管理动态数量的资源contextlib.ExitStack是个高级工具适合处理“直到运行前才知道有多少资源需要清理”的场景。比如你要打开一个数量不定的文件列表还要保证全部关闭from contextlib import ExitStack def open_many(paths): with ExitStack() as stack: files [stack.enter_context(open(p)) for p in paths] # 此时所有文件都打开了如果业务逻辑出错 # ExitStack退出时会逆序关闭所有已打开的文件 return files # 注意return后文件会立即全部关闭有一个特别容易踩的点在上面注释里写了ExitStack的清理发生在with块退出时。如果你在with块内把文件列表return出去等调用方拿到文件对象时文件其实已经被关闭了。因为函数返回值是先结算然后在退出with上下文时才执行清理动作吗注意顺序是先执行return files这个表达式得到文件对象列表然后才退出ExitStack上下文并关闭文件。所以外部拿到的是一堆已关闭的文件对象。如果想返回仍然可用的文件对象就不能把它们放在ExitStack的作用域内关闭得把ExitStack的生命周期延伸到外层。一个办法是提前实例化ExitStack对象手动管理它的close()class MultiFileOpener: def __init__(self, paths): self.paths paths self.stack ExitStack() self.files [] def __enter__(self): for p in self.paths: self.files.append(self.stack.enter_context(open(p))) return self.files def __exit__(self, exc_type, exc_val, exc_tb): self.stack.close() return False这样使用方可以在上下文存活期间正常读写文件退出时统一关闭。这个模式在处理“批量上传”“批量备份”这类场景时特别顺手。5.3 上下文管理器不适合用在哪写到最后我也得提一下反模式。上下文管理器虽然强大但不是万能的不应该用来隐藏“长时间运行的业务逻辑”。如果with块里有几千行业务代码上下文管理的“边界感”会大大削弱。它更适用于“边界清晰、进入和退出都是干净动作”的场景。不要为了“少写两行”而强行引入自定义上下文管理器。如果进入和退出逻辑特别复杂类本身还维护大量状态那直接用普通函数封装可能更好读。不要过度嵌套多个上下文管理器。多于3个的时候建议用ExitStack或者拆分成多个更小的上下文可读性会好很多。在我自己的项目里上下文管理器用得最多的地方其实是那些“以前总是忘了还原”的地方——临时配置、事务边界、锁的获取与释放、日志级别切换。每当你发现自己写出“记住要还原XX”这种注释时就是引入自定义上下文管理器最好的时机。最后再分享一个多年养成的习惯我写__exit__时第一行永远是if exc_type is not None: log(...)把异常信息先记录下来再做清理最后再根据需求决定返回True还是False。这个习惯帮我在排查生成环境问题时节省了大量时间——很多异常在你肉眼看到之前就已经被上下文管理器留下了痕迹。