with语句是Python中资源管理的最佳实践，它通过上下文管理器协议（__enter__和__exit__方法）确保资源的初始化与释放。使用with语句可自动处理文件、锁、数据库连接等资源的打开与关闭，无论代码块是否抛出异常，都能保证资源被正确清理，避免泄露。其核心优势在于提升代码的可读性、简洁性和异常安全性。相比传统的try…finally模式，with语句将资源管理逻辑封装在上下文管理器中，实现关注点分离，符合DRY原则。开发者可通过定义__enter__和__exit__方法来自定义上下文管理器，或利用contextlib模块中的@contextmanager装饰器、closing()、suppress()等工具快速创建上下文管理器，广泛应用于计时、临时目录切换、异常抑制等多种场景。掌握with语句及其生态是编写高质量Python代码的关键。
with
语句在 Python 中，本质上是一种优雅且安全的资源管理机制。它确保了资源（比如文件、网络连接、锁等）在使用前被正确地初始化，并在使用后，无论程序是否发生异常，都能被可靠地清理和释放。这大大简化了代码，避免了常见的资源泄露问题，让我们的程序更加健壮。核心在于它依赖于“上下文管理器”协议，通过特定的方法来控制资源的生命周期。
解决方案
with
语句的使用非常直观。当它与一个支持上下文管理协议的对象（即上下文管理器）结合时，Python 会在进入
with
块之前调用该对象的
__enter__
方法，并在退出
with
块（无论是正常退出还是发生异常）之后调用
__exit__
方法。
最经典的例子就是文件操作：
# 不使用 with 语句，需要手动关闭文件，容易忘记或处理异常不当# file_obj = open('my_file.txt', 'w')# try:# file_obj.write('Hello, world!')# finally:# file_obj.close()# 使用 with 语句，Python 会自动管理文件的开启和关闭with open('my_file.txt', 'w', encoding='utf-8') as f: f.write('你好，世界！n') f.write('这是 with 语句的魅力。n')# 文件在 with 块结束后自动关闭，即使中间发生错误print("文件写入完成，文件已自动关闭。")
在这个例子中，
open()
函数返回的文件对象就是一个上下文管理器。当
with open(...) as f:
语句执行时：
立即学习“Python免费学习笔记（深入）”；
open()
返回的文件对象的
__enter__
方法被调用。它会打开文件，并返回文件对象本身，这个对象被赋值给
f
。
with
块中的代码开始执行，我们可以通过
f
对文件进行读写操作。无论
with
块中的代码是正常执行完毕，还是在执行过程中抛出了异常，文件对象的
__exit__
方法都会被调用。
__exit__
方法负责关闭文件，确保资源被正确释放。
这不仅让代码更简洁，更重要的是，它提供了一种强大的异常安全保证。
为什么说
with
with
语句是Python资源管理的最佳实践？
在我看来，
with
语句之所以被认为是Python资源管理的“最佳实践”，主要因为它完美地解决了传统资源管理模式中那些令人头疼的问题，特别是围绕着“清理”这个环节。以前，处理需要显式打开和关闭的资源（比如文件、数据库连接、网络套接字，甚至是线程锁）时，我们通常会用到
try...finally
结构。
import threadinglock = threading.Lock()# 传统方式，需要手动获取和释放锁lock.acquire()try: print("线程安全操作进行中...") # 可能会发生异常的代码except Exception as e: print(f"操作失败: {e}")finally: lock.release()print("锁已释放。")
这种
try...finally
模式本身没错，它确实能保证
finally
块的代码无论如何都会执行。但问题在于，随着资源类型的增多，或者逻辑的复杂化，这种模式会迅速变得臃肿和难以维护。想象一下，如果一个函数需要同时打开多个文件、获取多个锁、连接多个数据库，那
try...finally
就会嵌套得让人头晕，而且一旦中间某个环节出错了，资源的释放顺序、是否所有资源都能被正确释放，都成了潜在的bug源。
with
语句的出现，就像是给这些“资源”穿上了一层自动管理的“外衣”。它把资源初始化 (
__enter__
) 和资源清理 (
__exit__
) 的逻辑封装在上下文管理器内部，使用者只需要关心
with
块内的核心业务逻辑，而无需操心资源什么时候打开、什么时候关闭。这种分离关注点的设计，让代码变得异常清晰、简洁。
更关键的是，
with
语句是天生“异常安全”的。无论
with
块内部发生什么异常，
__exit__
方法都会被调用，从而确保资源得到释放。这与
try...finally
的效果相同，但
with
的语法糖使得它更具可读性和优雅性。在我看来，它就是Python在工程实践中对“DRY”（Don’t Repeat Yourself）原则和“可读性优先”理念的绝佳体现。它把那些重复的、容易出错的资源管理代码抽象化了，让我们能更专注于解决实际问题，而不是陷在繁琐的资源生命周期管理中。这东西真的好用，用过就回不去了。
如何自定义上下文管理器？
__enter__
__enter__
和
__exit__
方法深度解析
自定义上下文管理器，是理解
with
语句工作原理的关键。它允许我们为任何需要“设置-清理”模式的资源或操作，创建自己的
with
兼容对象。要实现一个上下文管理器，你只需要创建一个类，并实现两个特殊方法：
__enter__(self)
和
__exit__(self, exc_type, exc_val, exc_tb)
。
让我们来创建一个简单的自定义计时器上下文管理器，用于测量代码块的执行时间：
import timeclass MyTimer: def __enter__(self): self.start_time = time.time() print("计时开始...") return self # 通常返回 self 或其他需要在 with 块中使用的对象 def __exit__(self, exc_type, exc_val, exc_tb): end_time = time.time() duration = end_time - self.start_time print(f"计时结束。代码块执行了 {duration:.4f} 秒。") # 处理异常： # exc_type: 异常类型 (e.g., TypeError, ValueError) # exc_val: 异常实例 # exc_tb: 异常的追踪信息 (traceback) if exc_type is not None: print(f"在计时块中捕获到异常：{exc_type.__name__}: {exc_val}") # 如果 __exit__ 返回 True，则表示异常已被处理，不会再次向上抛出。 # 如果返回 False (或不返回任何值，默认为None)，则异常会继续传播。 # 这里我们选择不抑制异常，让它继续传播，除非我们有特殊处理逻辑。 # return True # 如果想抑制异常，可以返回 True print("清理工作完成。") # 默认返回 None，意味着如果发生异常，异常会继续传播 # 如果返回 True，则表示异常已被处理，不会再次向上抛出。 # return False # 显式返回 False，与不返回相同效果
现在，我们用它来计时：
with MyTimer(): print("正在执行一些耗时操作...") time.sleep(0.5) # 模拟一个可能发生的错误 # raise ValueError("哦豁，出错了！") print("耗时操作完成。")print("n--- 带有异常的例子 ---")try: with MyTimer(): print("执行可能出错的操作...") time.sleep(0.2) result = 1 / 0 # 故意制造一个ZeroDivisionError print(f"结果是: {result}")except ZeroDivisionError: print("外部捕获到了 ZeroDivisionError。")
__enter__(self)
方法：
作用： 在
with
块开始执行之前被调用。它负责资源的初始化、设置或获取。返回值： 这个方法的返回值会被赋给
with ... as var:
语句中的
var
。如果不需要在
with
块内部使用该对象，可以返回
self
或者
None
。在我们的
MyTimer
例子中，它返回
self
，但实际上我们并没有在
with
块内部使用
MyTimer
实例，所以返回
None
也是可以的。如果返回的是文件对象，那么
as
后面的变量就能直接操作文件了。
__exit__(self, exc_type, exc_val, exc_tb)
方法：
作用： 在
with
块结束时（无论是正常结束还是因为异常结束）被调用。它负责资源的清理、释放或关闭。参数：
exc_type
: 如果
with
块中发生了异常，这个参数会是异常的类型（例如
ZeroDivisionError
）。如果没有异常，它就是
None
。
exc_val
: 如果有异常，这是异常的实例（例如
ZeroDivisionError('division by zero')
）。如果没有异常，它就是
None
。
exc_tb
: 如果有异常，这是异常的追踪信息（traceback）。如果没有异常，它就是
None
。返回值：如果
__exit__
方法返回
True
，则表示它已经“处理”了
with
块中发生的异常，Python 不会再将这个异常向上传播。这意味着异常被“抑制”了。如果
__exit__
方法返回
False
（或者不返回任何值，因为默认返回
None
），则表示它没有处理异常，Python 会继续将异常向上传播，就像
with
语句不存在一样。在我们的
MyTimer
例子中，我们选择让异常继续传播，所以没有返回
True
。这通常是推荐的做法，除非你有明确的理由去抑制异常。
通过自定义上下文管理器，我们能够将任何一对“设置-清理”操作封装起来，使其能够与
with
语句无缝协作，极大地提升了代码的模块化和鲁棒性。
除了文件操作，
with
with
语句还能用在哪些场景？
contextlib
模块的妙用
with
语句的强大远不止于文件操作。任何需要“获取-释放”模式的资源，或者需要“进入-退出”状态转换的场景，都可以通过上下文管理器来优雅地处理。
常见的应用场景：
线程/进程锁 (Locking): 在多线程或多进程编程中，为了避免竞态条件，我们经常需要获取锁并在操作完成后释放锁。
threading.Lock
和
multiprocessing.Lock
对象都是上下文管理器。
import threadingmy_lock = threading.Lock()shared_data = 0def increment(): global shared_data with my_lock: # 自动获取锁 # 这段代码是线程安全的 temp = shared_data temp += 1 shared_data = temp # 锁在 with 块结束后自动释放 print(f"线程 {threading.current_thread().name} 完成，shared_data: {shared_data}")threads = [threading.Thread(target=increment, name=f"Thread-{i}") for i in range(5)]for t in threads: t.start()for t in threads: t.join()print(f"最终 shared_data: {shared_data}")
数据库连接 (Database Connections): 连接到数据库、执行操作、然后关闭连接是另一个典型场景。许多数据库库的连接对象都设计成了上下文管理器。
# 假设有一个简化的数据库连接类class DatabaseConnection: def __init__(self, db_name): self.db_name = db_name self.connection = None def __enter__(self): print(f"连接到数据库: {self.db_name}...") # 模拟实际连接操作 self.connection = f"Connected to {self.db_name}" return self.connection def __exit__(self, exc_type, exc_val, exc_tb): if self.connection: print(f"关闭数据库连接: {self.db_name}...") # 模拟实际关闭操作 self.connection = None if exc_type: print(f"数据库操作发生异常: {exc_type.__name__}: {exc_val}")with DatabaseConnection("my_app_db") as db: print(f"正在使用连接: {db}") # 执行数据库查询、更新等操作 # raise ValueError("模拟数据库操作失败")print("数据库连接已处理。")
网络套接字 (Network Sockets): 建立网络连接、发送/接收数据、关闭连接。
临时改变环境 (Temporary Context Change): 例如，临时改变当前工作目录，或临时修改某个配置。
contextlib
模块的妙用：
Python 标准库中的
contextlib
模块提供了一些非常实用的工具，可以更方便地创建和使用上下文管理器，尤其是在你不想写一个完整的类时。
@contextmanager
装饰器：这是
contextlib
中最常用的工具。它允许你用一个简单的生成器函数来创建上下文管理器，而无需定义一个类并实现
__enter__
和
__exit__
方法。生成器函数在
yield
之前的部分相当于
__enter__
，
yield
返回的值就是
__enter__
的返回值，而
yield
之后的部分则相当于
__exit__
。
from contextlib import contextmanagerimport time@contextmanagerdef simple_timer(): start_time = time.time() print("（通过生成器）计时开始...") try: yield # 这里的 yield 相当于 __enter__ 的返回值，如果 with ... as var:，var 就得到 yield 的值 except Exception as e: print(f"（通过生成器）在计时块中捕获到异常：{type(e).__name__}: {e}") # 如果不重新抛出异常，异常会被抑制。 # raise # 如果想让异常继续传播，可以在这里重新抛出 finally: end_time = time.time() duration = end_time - start_time print(f"（通过生成器）计时结束。代码块执行了 {duration:.4f} 秒。")with simple_timer(): print("执行一些生成器计时操作...") time.sleep(0.3) # raise TypeError("模拟生成器计时错误")print("生成器计时器已处理。")
这种方式写起来非常简洁，对于那些逻辑相对简单的上下文管理场景，是首选。
closing(thing)
：这个函数可以将任何具有
close()
方法的对象包装成一个上下文管理器。如果你有一个第三方库的对象，它只提供了
close()
方法，但没有实现上下文管理器协议，
closing
就能派上用场。
from contextlib import closing# 假设这是一个没有实现上下文管理协议的资源class MyResource: def __init__(self, name): self.name = name print(f"资源 '{self.name}' 已打开。") def close(self): print(f"资源 '{self.name}' 已关闭。") def do_something(self): print(f"资源 '{self.name}' 正在工作。")with closing(MyResource("临时文件句柄")) as res: res.do_something()print("资源处理完成。")
*`suppress(exceptions)`：**这个上下文管理器用于临时抑制指定的异常。在某些情况下，你可能知道某个操作可能会抛出特定异常，但你希望程序继续执行，而不是中断。
from contextlib import suppresswith suppress(FileNotFoundError): # 尝试打开一个不存在的文件，通常会抛出 FileNotFoundError # 但在这里，这个异常会被 suppress 捕获并忽略 with open("non_existent_file.txt", "r") as f: content = f.read() print(content) print("文件读取尝试完成 (如果文件存在)。")print("程序继续执行，即使文件不存在。")with suppress(ZeroDivisionError): result = 10 / 0 print(f"这个不会打印，因为异常被抑制了: {result}")print("除零错误被抑制，程序继续。")
with
语句及其背后的上下文管理器协议，配合
contextlib
模块，为 Python 开发者提供了一套强大、灵活且异常安全的资源管理工具。它不仅仅是一种语法糖，更是一种设计模式，鼓励我们编写更健壮、更易读的代码。在我看来，掌握它，是成为一名优秀 Python 程序员的必经之路。
以上就是Python怎么使用with语句_with语句与上下文管理器详解的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1371332.html
微信扫一扫 
支付宝扫一扫 
