Python如何实现上下文管理_通过__enter__与__exit__自定义with语句-Python教程-PHP中文网

__enter__和__exit__必须成对实现，因with语句强制调用二者；缺一即报AttributeError或TypeError，且__exit__中仅返回True可抑制异常。

python如何实现上下文管理_通过__enter__与__exit__自定义with语句

为什么`enter`和`exit`必须成对实现

单独定义__enter__或__exit__没有意义——Python 的 with 语句在进入时调用__enter__，退出时**一定**调用__exit__，哪怕发生异常。如果缺__exit__，with会直接报 AttributeError: __exit__。

常见错误现象：TypeError: object does not support the context manager protocol，本质就是类没实现这两个方法，或拼写错误（比如写成_enter_少了一个下划线）。

实操建议：

__enter__ 返回值会绑定到 as 后的变量，若不需要暴露对象，可返回 self 或 None
__exit__(self, exc_type, exc_value, traceback) 四个参数必须齐全，即使不使用也要保留占位；其中前三个为 None 表示未发生异常
若在__exit__中返回 True，会吞掉异常（不传播），这是显式抑制错误的唯一合法方式

如何让`exit`正确处理异常而不吞掉它

多数自定义上下文管理器不该吞异常——比如文件操作失败应该让调用方知道。但新手常误写 return True 或漏掉 return False（Python 默认返回 None，等价于 False，所以通常不用显式写）。

实操建议：

只在明确要屏蔽某类异常时才返回 True，例如忽略 FileNotFoundError 而继续执行
若需记录异常但不抑制，应在 __exit__ 中做日志，然后不返回或返回 False
避免在 __exit__ 中 raise 新异常，否则会覆盖原始异常；如真需转换，用 raise new_exc from exc_value

示例：安全关闭资源，但不干扰业务异常

def __exit__(self, exc_type, exc_value, traceback):
    self.close()  # 总是执行清理
    # 不 return，等价于 return False → 原异常照常抛出

用`@contextlib.contextmanager`替代手写`enter`/`exit`的适用场景

当逻辑简单、无状态、只需“进前 setup + 出后 teardown”时，@contextlib.contextmanager 更轻量。它把函数体拆成两段：yield 之前是 __enter__，之后是 __exit__。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

但要注意：装饰器版本无法直接访问实例属性，也不能复用已有类结构；且 yield 必须出现一次且仅一次。

实操建议：

适合一次性工具，比如临时修改环境变量、切换工作目录、打点计时
yield value 的 value 就是 as 接收的对象；不写 yield 则 as 得到 None
异常会在 yield 处抛出，yield 后的代码仍会执行（类似 finally），可用于清理

示例：临时设置超时

from contextlib import contextmanager
import signal
<p>@contextmanager
def timeout(seconds):
def timeout_handler(signum, frame):
raise TimeoutError("Operation timed out")
old_handler = signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(seconds)
try:
yield
finally:
signal.alarm(0)
signal.signal(signal.SIGALRM, old_handler)
</p>