写Python的人几乎每天都跟with打交道。打开文件、拿锁、跑数据库事务随手就是一句with ... as ...。但你有没有想过这看似简单的语法糖背后到底藏着一套什么样的机制为什么它能保证资源一定被释放为什么__exit__里写return True就能吞掉异常为什么有时候自定义上下文管理器用类实现有时候又用contextlib.contextmanager装饰器这些看似零散的问题其实都指向同一个核心概念——上下文管理器协议。这篇博文我就从原理讲到实践把with语句的来龙去脉、__enter__/__exit__的执行细节、contextlib的常用工具、自定义上下文管理器的两种方式以及我在实际项目中踩过的几个坑一次性说透。不管你是刚入门Python的初学者还是已经写了好几年代码的老手这篇文章都能让你对with有一个更完整的认识。1. 先搞清楚为什么我们离不开with1.1 资源管理的老大难问题在Python还没流行with语句的年代或者说在你完全不使用with的代码里资源管理是一件非常痛苦的事情。拿最经典的文件操作来说你写出来的代码往往是这样的f open(data.txt, r, encodingutf-8) data f.read() f.close()然后问题就来了如果f.read()中间抛了个异常后面的f.close()根本不会执行文件句柄就永远留在那里了。虽然现代操作系统在你进程退出时会回收但如果你写的是一个长时间运行的服务每出错一次泄漏一个句柄用不了多久就会报Too many open files。所以大家就学会了用try/finally来兜底f open(data.txt, r, encodingutf-8) try: data f.read() finally: f.close()这段代码确实能保证不管read()是否报错close()一定执行。但你看这写法六行代码里只有一行是真正干活的剩下全在做资源清理。如果程序里到处都是这种结构代码就会变得非常啰嗦而且很容易出现忘了写finally或者finally里忘了关闭的情况。1.2 with一下子把样板代码压缩掉了with语句解决的就是这个问题。同样的事情用with来写只需要三行with open(data.txt, r, encodingutf-8) as f: data f.read()不仅代码变短了关键是资源一定会被清理这件事有了机制层面的保证不再依赖程序员的自觉。你只要进入了with代码块不管中间是正常执行完还是抛出异常甚至是你手动敲了CtrlC触发了KeyboardInterrupt上下文管理器都会严格执行清理逻辑。诚然有人会觉得不就是少写两行代码吗有什么了不起的但如果把这个思路推广到锁的获取与释放、数据库事务的提交与回滚、临时修改环境变量后的恢复等场景你就知道with的意义远不止少写两行这么简单。1.3 上下文管理器解决的本质问题除了文件操作类似的资源管理问题还出现在很多地方。比如多线程编程里的锁lock threading.Lock() lock.acquire() try: # 临界区代码 pass finally: lock.release()再比如数据库操作里的游标cursor conn.cursor() try: cursor.execute(SELECT ...) finally: cursor.close()上下文管理器的本质就是把获取资源和释放资源这两个动作绑定在一起并保证释放动作在任何情况下都会执行。荣获Python最佳语法糖称号它当之无愧。懂了这个底层逻辑你就能明白为什么Python社区会这么推崇with也会在后面自己写自定义上下文管理器时知道设计的核心该往哪个方向使劲。2. 上下文管理器到底是一个什么协议2.1 两个魔法方法__enter__和__exit__要说清楚with的机制就必须说清楚上下文管理器协议。在Python里只要一个类同时实现了__enter__和__exit__这两个方法它就是一个上下文管理器。__enter__(self)进入with代码块之前调用负责获取资源。如果with语句后面有as xxx它的返回值会赋给xxx。__exit__(self, exc_type, exc_val, exc_tb)退出with代码块时调用负责释放资源。异常发生时这三个参数会分别携带异常类型、异常实例和traceback对象。先看一个最简单的自定义上下文管理器用来直观感受这个协议class MyContext: def __enter__(self): print(进入上下文) return 42 def __exit__(self, exc_type, exc_val, exc_tb): print(退出上下文) return False with MyContext() as num: print(fnum 的值是 {num})输出进入上下文 num 的值是 42 退出上下文2.2 with语句到底做了什么很多人以为with是Python解释器里的魔法关键字但它其实有非常清晰的展开逻辑。with EXPR as TARGET:这个语句解释器内部大致做了这么几件事调用EXPR.__enter__()方法拿到一个返回值。如果有as TARGET把返回值赋给TARGET。执行with代码块。代码块结束后调用EXPR.__exit__(None, None, None)。如果代码块抛出了异常调用EXPR.__exit__(exc_type, exc_val, exc_tb)然后根据__exit__的返回值决定是否抑制这个异常。第五步是个关键点值得展开说说。__exit__返回False默认就是False异常会继续向外部传播返回True就表示这个异常我已经处理了异常不会被抛出到with外面。逐行看一段代码就清楚了class DemoExit: 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 with DemoExit(): raise ValueError(something wrong)这段程序运行后你会在控制台看到捕获到异常: ValueError: something wrong然后紧接着是traceback的输出因为return False表示异常没有被吞掉它会继续往外抛。如果你把return False改成return True程序就会安安静静地结束不会报错。2.3 __exit__这个坑返回值不是装饰给人看的我见过不少新手在写__exit__的时候随手写了个return None或者return False这都没问题异常正常往外传播是合理的默认行为。但有一种情况很容易踩坑为了让代码更干净而在__exit__里写了return True结果异常静默消失了排查了半天bug都找不到源头。更好的做法是在__exit__里记录日志、做清理操作然后老老实实返回False让异常继续往上抛。这样调用方该看到异常还是会看到而清理工作也一点没落下。如果你确实想吞掉某个特定异常建议在__exit__内部先判断exc_type是否为你期望的类型不要无脑return True。2.4 __enter__的返回值到底给了谁这个说起来简单但也不少人迷糊。with open(...) as f:里f拿到的是open(...)返回的文件对象本身因为文件对象的__enter__方法返回的就是self。但很多自定义上下文管理器的__enter__返回值用得不好。比如你写了一个连接池管理器class Pool: def __enter__(self): return self.acquire_conn() def __exit__(self, exc_type, exc_val, exc_tb): self.release_conn() return False这里__enter__返回的是从池里取出的连接对象as conn拿到的就是具体的连接这样设计就很自然。注意一个细节__enter__的返回值和__exit__的接收参数不是一套东西__exit__只负责收异常信息所以如果你想在退出时访问到进入时的那批数据就得自己把状态存在实例属性里不能指望__exit__拿到__enter__的返回值。3. 几条好用的内置与contextlib工具3.1 文件对象和线程锁Python标准库里最经典的上下文管理器就是文件对象和threading.Lock。文件对象是从Python 2.5开始支持with协议的文件对象的__enter__返回self也就是文件对象本身__exit__负责调用close()。所以你在with块里读写文件完全不需要手动close。线程锁也是只要锁对象实现了上下文管理器协议就能这样写import threading lock threading.Lock() with lock: # 这里就是临界区 count 1你可能没意识到with lock:其实等价于lock.acquire() try: count 1 finally: lock.release()不过这里有个容易忽略的点Lock的__enter__不接收参数、也不返回东西它的__exit__也不会吞异常无论临界区代码是否报错都会执行release()。这正好体现了上下文管理器的最核心价值保证释放。3.2 contextlib里那些被低估的工具Python标准库contextlib模块是我个人非常喜欢的一个模块。它里面藏着不少好东西以下几个是我在项目中经常用到的closing如果你手头有一个对象它只有close()方法没有实现上下文管理器协议可以用contextlib.closing包一下from contextlib import closing with closing(urllib.urlopen(http://example.com)) as response: content response.read()suppress想忽略特定异常但又不想写一长串try/except可以这样from contextlib import suppress import os with suppress(FileNotFoundError): os.remove(not_exist.txt)这个工具比我前面提到的__exit__里return True要优雅得多而且职责单一不会影响别处对异常的观察。我自己写脚本清理临时文件时几乎总会用到它。redirect_stdout临时把print的输出重定向到文件或字符串缓冲区调试或者做日志收集时特别好用from contextlib import redirect_stdout import io buf io.StringIO() with redirect_stdout(buf): print(这段文字不会打印到控制台) print(buf.getvalue())3.3 ExitStack动态管理一堆上下文管理器如果你以为contextlib就是以上几个小工具那就太小看它了。ExitStack才是真正的王炸它允许你在代码运行过程中动态注册释放回调从而把多个上下文管理器组合在一起统一管理。典型场景你要同时打开多个文件但文件数量在运行前不知道。老写法是files [] try: for path in path_list: files.append(open(path, r, encodingutf-8)) # 操作所有文件 finally: for f in files: f.close()用ExitStack可以写得清晰、安全很多from contextlib import ExitStack with ExitStack() as stack: files [stack.enter_context(open(path, r, encodingutf-8)) for path in path_list] # 操作所有文件 # 无论中间是否抛异常ExitStack 都会按后进先出的顺序自动关闭这个工具在我处理多个临时文件、多个锁、或动态分配资源时非常有用。你可以随时通过stack.enter_context()把新的资源纳入管理退出时会按逆序统一清理完全不用自己操心释放顺序的问题。4. 自定义上下文管理器实操指南4.1 方式一写一个类实现协议自定义上下文管理器最直接的方式就是定义一个类并实现__enter__和__exit__。我拿一个实际项目中用过的例子来讲一个用于性能统计的计时器。import time class Timer: def __enter__(self): 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:.4f}s) return False with Timer() as t: # 随便做点什么 time.sleep(0.2) print(f外部也能访问到耗时: {t.elapsed:.4f}s)这个类的好处是__enter__返回self外部通过as t拿到的就是Timer实例本身代码块结束后实例的属性elapsed依然可以被外部访问到。如果你用__enter__返回一个别的对象这个计时数据就可能拿不到了。在实际项目中我还经常在这个基础上扩展比如把耗时写入日志、统计平均耗时、判断是否超时并发告警。思路都差不多核心就是在__exit__里做收尾动作。4.2 方式二用contextmanager装饰器代码更精简如果你觉得写一个类太啰嗦Python还提供了更优雅的方式contextmanager装饰器。它允许你把一个生成器函数变成一个上下文管理器核心逻辑就用yield来切分进入和退出两段。from contextlib import contextmanager contextmanager def timer(): start time.perf_counter() try: yield finally: elapsed time.perf_counter() - start print(f耗时: {elapsed:.4f}s) with timer(): time.sleep(0.2)看到区别了吗yield之前的代码是进入时执行yield之后的代码是退出时执行。yield给出去的东西就是withas拿到的值。这种写法在需要快速封装一个资源管理逻辑时特别方便不需要为一个临时小需求专门定义一个类代码一眼就能看明白。如果你需要设计进入时获取A退出时释放B装饰器方式无疑是最合适的。4.3 contextmanager装饰器怎么处理异常使用装饰器方式时如果你想处理代码块内抛出的异常需要在yield周围套上try/exceptcontextmanager def ignore_exception(exc_type): try: yield except exc_type: pass如果你完全不处理异常那么yield处的异常会直接抛出去不影响外层。这一点跟类方式的__exit__返回值语义有点不同类方式是用返回值来控制是否抑制异常装饰器方式是用生成器内部的异常处理来控制。我个人经验是装饰器方式写起来更自然但你得在脑子里时刻想着yield就是分界线这件事。4.4 两种方式怎么选用一个表格总结一下方便你日后选择对比维度类实现装饰器实现代码结构一个类两个方法一个生成器函数可读性稍显啰嗦但逻辑直观紧凑yield前后切分清晰状态保存通过实例属性外部可访问函数内局部变量需要外部访问时得用可变容器异常处理通过__exit__返回值和参数通过yield周围的try/except适用场景复杂逻辑、需要被多个地方复用且带状态简单快捷、一次性封装、临时改动如果你写的是项目里会被反复复用的基础组件比如连接池、事务管理器类实现更合适。如果你只是想在某个业务流程里临时包一下资源装饰器方式顺手就写了。5. 实战场景把with用到业务抽象里5.1 场景一数据库事务的提交与回滚这是我认为上下文管理器最能发光发热的场景之一。以前写数据库操作最麻烦的就是事务控制要么忘记commit要么异常后没回滚导致数据状态错乱。用上下文管理器可以把这套逻辑彻底收敛掉from contextlib import contextmanager contextmanager def transaction(connection): try: yield connection connection.commit() except Exception: connection.rollback() raise用法with transaction(conn) as c: c.execute(INSERT INTO users (name) VALUES (%s), (张三,)) c.execute(UPDATE accounts SET balance balance - 100 WHERE id 1)这段代码的意思是只要with块里的操作全部成功就统一提交中途任何一步抛异常就回滚整个事务并把异常继续抛出去让调用方处理。这样你每个业务函数里就不需要重复写commit和rollback的样板代码了。5.2 场景二临时修改环境变量并恢复有时候程序需要临时设置某个环境变量或修改sys.path用完必须恢复原样否则会影响后续逻辑。这种场景用上下文管理器做“快照恢复”特别顺手import os from contextlib import contextmanager contextmanager def set_env(key, value): old_value os.environ.get(key) os.environ[key] value try: yield finally: if old_value is None: del os.environ[key] else: os.environ[key] old_value这在配置测试环境、切换CI参数时非常实用。你只需要把当前值是什么存下来退出时回到原状态就够了。这个模式在后续扩展中还能泛化成任意变量快照不止是环境变量。5.3 场景三组合多个上下文管理器不同上下文管理器可以随意组合。常见的方式是写成多个with嵌套或者用括号把多个with合并到一行with open(in.txt, r, encodingutf-8) as fin, \ open(out.txt, w, encodingutf-8) as fout: fout.write(fin.read())Python的with是支持同时打开多个的注意不管哪一个中间出现异常两个文件都会被正常关闭。如果你要管理的一串资源是动态数量的就回归到前面提到的ExitStack那里才是它擅长的主场。6. 踩过的坑与大坑速查表6.1 坑一__exit__里做资源清理时又抛异常假设你在__exit__里做清理比如关闭网络连接结果关闭这个动作本身报错了。这时候新异常会取代原有异常导致原始的traceback丢失排查问题时非常头疼。我的建议是__exit__里的清理逻辑尽量简单最好只做这种能不做就不做的事情。如果清理可能失败先捕获并打日志避免覆盖正在传播的原始异常。6.2 坑二以为with能解决线程安全问题不要把上下文管理器跟线程安全画等号。with lock:能保证锁的释放但锁内部的临界区代码是否安全完全取决于你的代码怎么写。同样with open(...)也管不了多个线程同时读写同一个文件的问题。有些新手看到with就以为线程安全了这是天大的误解。6.3 坑三在contextmanager装饰器里忘写try/finally装饰器方式的上下文管理器有一个容易踩的坑如果在yield之后、函数结束前抛了异常这个异常很难被调用方捕获到。比如contextmanager def bad_cm(): yield raise RuntimeError(cleanup failed)当with块正常结束时这个RuntimeError会在with语句的退出点抛出直接被抛出到外部。如果调用方在with外面就包了try/except RuntimeError它会被捕获到但那种退出时出现了奇怪崩溃的感受仍然很糟糕。正确做法是把清理逻辑放在finally里让它作为清理动作的一部分而不是主流程的异常。6.4 坑四文件操作的编码错误被with掩盖了这算是我遇到过的一个很实际的例子。有一次我从某个接口下载文件用了with open保存但文件编码是GBK而代码里用utf-8读取结果解码时抛出UnicodeDecodeError。因为with的__exit__会先于异常传播执行文件虽然被正确关闭了但异常信息没有明确指向读取编码不对调试时花了不少时间。给个简单建议如果你在with块里读写二进制或编码敏感的内容先用try/except捕获异常并附加上下文再让异常往外抛。这样排查起来会痛快很多。6.5 常见问题速查表问题现象可能原因解决办法with结束后资源没释放__exit__里没做清理或异常在清理前中断检查__exit__实现确保清理逻辑放在finally里异常被静默吞掉__exit__返回了True默认返回False只在确认要吞掉特定异常时返回True多个with嵌套顺序乱了依赖了with嵌套的退出顺序用ExitStack管理或显式控制嵌套顺序代码块正常退出时报错__exit__或yield之后的清理代码抛异常清理代码用try/except包裹记录日志7. 从一个实际项目里得到的教训我以前维护过一个小型数据处理服务里面有一段代码需要从多个接口拉取数据然后写库。刚开始我图省事用了一个类似suppress(Exception)的写法把所有异常都吞掉了想着“处理失败就算了不阻塞主流程”。结果生产环境上跑了一段时间后发现有一批数据一直没写进去排查了大半天才发现异常被静默吞了数据库里缺了整整一个批次的数据。后来我改成全面使用上下文管理器来管理资源每个数据源用独立的with块读取数据库写入用自己封装的事务上下文管理器异常的日志照常记录但不再无脑吞掉。这样既保证了失败不阻塞主流程也让问题可追踪。从那以后我对“吞异常”这件事就格外谨慎也算是在真实项目里踩过坑之后总结出的经验。如果你也想在你的项目里用好上下文管理器我的建议很简单先从最常见的文件、数据库事务、锁这几个场景入手慢慢过渡到自定义业务场景的封装。等你习惯了这种“进入-退出”的思维模式你会发现它不仅仅是一个语法糖而是一种“把资源的生命周期管好”的思维方式。以后再写资源相关代码不妨先想想这个资源能不能用with来管理