with语句通过上下文管理器协议确保资源在进入和退出代码块时被正确初始化和清理，即使发生异常也能自动释放资源，从而避免资源泄漏；它通过__enter__和__exit__方法或contextlib的@contextmanager装饰器实现，使文件、数据库连接等资源管理更安全、简洁。
with
语句在 Python 里，说白了，就是一种优雅地处理资源（比如文件、网络连接、锁）的方式，它能确保这些资源在使用完毕后，不管过程中有没有出错，都能被妥善地清理掉。它的魔法源自“上下文管理器”协议，这个协议定义了对象如何进入和退出一个特定的代码块。
在编程实践中，我们经常需要处理一些有“生命周期”的资源：打开文件后要关闭，连接数据库后要断开，获取锁后要释放。如果手动去管理这些步骤，尤其是在代码路径复杂或者出现异常的情况下，很容易遗漏清理操作，导致资源泄漏或者程序行为异常。
with
语句就是为了解决这个痛点而生的。它通过与实现了特定方法的对象（也就是上下文管理器）协作，在进入
with
代码块时执行资源准备工作，在退出代码块时（无论正常退出还是异常退出）执行资源清理工作。这不仅让代码更简洁，也大大提高了程序的健壮性。
为什么我们要用
with
with
语句来处理文件或数据库连接？
我记得刚开始写Python的时候，处理文件都是这样：
f = open('my_file.txt', 'r'); data = f.read(); f.close()
。后来发现，如果
f.read()
出了问题，比如文件太大内存溢出，那
f.close()
就根本执行不到，文件句柄就一直开着，时间长了，系统资源就耗尽了。或者说，如果一个函数里有多个
return
语句，你还得在每个
return
之前都加上
f.close()
，想想都头大。
这就是
with
语句的价值所在。它最核心的优势在于“异常安全”和“自动化清理”。
拿文件操作来说，当你写
with open('my_file.txt', 'r') as f:
，Python 会在文件打开后，把文件对象赋值给
f
。当
with
块内的代码执行完毕，或者在执行过程中抛出了任何异常，Python 都会自动调用文件对象的清理方法（也就是关闭文件）。你完全不用操心
f.close()
，也不用写
try...finally
这样的结构。这不仅仅是代码量减少那么简单，更重要的是，它极大地降低了因疏忽而导致资源泄漏的风险。
数据库连接也是一个典型的例子。连接池中的连接是宝贵的资源，一个应用如果不断地获取连接而不释放，很快就会把连接池耗尽，导致其他请求无法获取连接。使用
with
语句来管理数据库连接，可以确保连接在事务完成后（或发生错误时）被自动归还给连接池，或者直接关闭，避免了资源浪费。这种模式让开发者可以更专注于业务逻辑，而不是繁琐的资源管理细节。
自己动手实现一个上下文管理器需要注意什么？
实现一个自定义的上下文管理器，其实就是让你的类遵循上下文管理器协议，也就是实现两个特殊方法：
__enter__
和
__exit__
。
__enter__(self)
方法会在
with
语句块被执行前调用。它的主要职责是进行资源的初始化和准备工作，并且它必须返回一个对象。这个对象就是
as
关键字后面跟着的变量所绑定的值。比如，
with MyResource() as res:
，
res
就会是
MyResource
实例的
__enter__
方法的返回值。如果你的资源对象本身就是你想要操作的对象，那么通常
__enter__
直接返回
self
就可以了。
__exit__(self, exc_type, exc_val, exc_tb)
方法则是在
with
语句块执行完毕后（无论是正常结束还是因为异常而中断）调用。这个方法负责资源的清理工作。它的三个参数非常关键：
exc_type
: 如果
with
块内发生了异常，这里就是异常的类型（比如
ValueError
）。如果没有异常，则是
None
。
exc_val
: 如果有异常，这里是异常实例本身。没有异常时是
None
。
exc_tb
: 如果有异常，这里是异常的追踪信息（traceback）。没有异常时是
None
。
在
__exit__
方法里，你可以根据
exc_type
是否为
None
来判断
with
块内是否发生了异常。如果你希望在
__exit__
方法中处理掉这个异常（比如记录日志后不再向上层抛出），那么
__exit__
方法需要返回
True
。返回
True
会告诉 Python 解释器，这个异常已经被妥善处理了，不要再继续向上抛出。如果返回
False
（或者不返回任何值，因为默认就是
None
，相当于
False
），那么异常会继续传播。
举个例子，假设我们要实现一个简单的计时器上下文管理器：
import timeclass MyTimer: def __enter__(self): self.start_time = time.time() print("计时开始...") return self # 返回自身实例，这样 with MyTimer() as timer: 就可以用 timer 了 def __exit__(self, exc_type, exc_val, exc_tb): end_time = time.time() duration = end_time - self.start_time print(f"计时结束，总耗时：{duration:.4f} 秒") if exc_type: # 如果有异常发生 print(f"with 块内发生异常：{exc_type.__name__}: {exc_val}") # 如果我们不想让异常继续传播，可以在这里返回 True # return True # 默认返回 None，即 False，异常会继续传播 print("资源清理完成。")# 使用示例with MyTimer(): print("正在执行一些耗时操作...") time.sleep(1.5) # raise ValueError("哦豁，出错了！") # 尝试解注释这行看看异常处理print("with 块外部代码继续执行。")
这里
__enter__
返回了
self
，所以
with MyTimer() as timer:
这里的
timer
就是
MyTimer
的实例。
__exit__
负责计算并打印耗时，同时展示了如何捕获异常信息。通过这样的设计，你可以封装任何需要“进入”和“退出”阶段的逻辑。
contextlib
contextlib
模块如何简化上下文管理器的创建？
说实话，每次都写一个类，然后实现
__enter__
和
__exit__
，对于一些简单的上下文管理任务来说，确实有点小麻烦。Python 的标准库
contextlib
就是来解决这个问题的，它提供了一些工具，让创建上下文管理器变得更简单，特别是
@contextmanager
装饰器。
@contextmanager
装饰器允许你用一个生成器函数来创建上下文管理器。它的原理是，在生成器函数中，
yield
关键字之前的所有代码，相当于
__enter__
方法的逻辑；
yield
语句本身返回的值，就是
__enter__
方法的返回值；而
yield
语句之后的所有代码，则相当于
__exit__
方法的逻辑。
我们来用
@contextmanager
重新实现上面的计时器：
from contextlib import contextmanagerimport time@contextmanagerdef simple_timer(): start_time = time.time() print("计时开始 (通过 contextlib)...") try: yield # 这里是 with 块的代码执行的地方 except Exception as e: print(f"with 块内发生异常 (通过 contextlib)：{type(e).__name__}: {e}") # 如果要抑制异常，这里可以不 re-raise，或者捕获后不抛出 # 也可以再次抛出，或者抛出新的异常 raise # 默认会重新抛出捕获到的异常 finally: end_time = time.time() duration = end_time - start_time print(f"计时结束 (通过 contextlib)，总耗时：{duration:.4f} 秒") print("资源清理完成 (通过 contextlib)。")# 使用示例with simple_timer(): print("正在执行一些耗时操作 (通过 contextlib)...") time.sleep(0.8) # raise TypeError("又出错了！") # 尝试解注释这行print("with 块外部代码继续执行 (通过 contextlib)。")
你看，是不是简洁多了？一个函数搞定一切。
yield
语句将生成器函数分割成了两个部分，完美地对应了
__enter__
和
__exit__
的行为。
try...except...finally
结构在
yield
周围，使得异常处理和清理逻辑变得非常直观。如果
yield
内部的代码抛出异常，这个异常会被
try...except
捕获，你可以在
except
块中处理它。如果
except
块没有重新抛出异常，那么异常就被抑制了。
finally
块则确保了清理代码无论如何都会执行。这种方式对于快速实现功能性上下文管理器，简直是神来之笔。
以上就是with 语句和上下文管理器（Context Manager）的原理的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1369766.html
微信扫一扫 
支付宝扫一扫 
