Python上下文怎么写_自定义enter与exit方法实现资源管理-Python教程-PHP中文网

__enter__ 和 __exit__ 必须成对出现，因为 with 语句强制调用二者；缺一即报 AttributeError 或 TypeError，且 __exit__ 必须接收三个参数并正确处理异常与清理逻辑。

python上下文怎么写_自定义enter与exit方法实现资源管理

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

因为 Python 的 with 语句在进入时强制调用 __enter__，退出时（无论是否异常）强制调用 __exit__；少一个，with 就直接报 AttributeError: __exit__ 或类似错误。

常见错误现象：with MyContext(): 报错 TypeError: 'MyContext' object is not a context manager，基本就是漏了 __exit__，或者拼错了名字（比如写成 __exxit__）。

__enter__ 返回值会绑定到 as 后的变量，不返回（即隐式返回 None）也合法，但多数场景要返回资源本身或关键对象
__exit__ 必须接收 3 个参数：exc_type、exc_value、traceback；哪怕全用 _ 忽略，也不能少参数，否则调用时崩溃
如果 __exit__ 返回 True，会吞掉异常；返回 False 或 None 才继续抛出——这是控制异常传播的关键开关

怎么让 `exit` 正确处理异常和清理逻辑

别在 __exit__ 里手动 raise 原异常，Python 已经帮你做了；重点是：先做清理，再决定是否压制异常。

典型使用场景：文件打开失败、网络连接中断、临时目录未删干净——这些都要在 __exit__ 里兜底。

清理操作（如关闭句柄、删除临时文件）必须放在 __exit__ 开头，避免因异常提前退出导致资源泄漏
判断是否有异常：用 if exc_type is not None:，而不是 if exc_value:，因为有些异常的 exc_value 可能为 falsy（比如 Exception("")）
不要在 __exit__ 里写复杂业务逻辑，它只该做“善后”；若需重试或转换异常，请在 with 块内处理

def __exit__(self, exc_type, exc_value, traceback):
    self._cleanup()  # 先清理
    if exc_type is not None:
        log_error(f"Caught {exc_type.__name__}: {exc_value}")
    return False  # 不压制异常

自定义上下文管理器 vs `contextlib.contextmanager` 怎么选

写类实现 __enter__/__exit__ 更适合需要保存状态、复用实例、或配合继承的场景；而 @contextmanager 更轻量，适合一次性的、逻辑简单的资源管理。

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

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

下载

性能差异不大，但兼容性有坑：装饰器方式生成的上下文管理器，在某些老版本 Python（如 3.6 之前）中可能不支持 __aenter__/__aexit__，而手写类更容易显式补全异步支持。

如果类里已有大量属性和方法，加两个魔术方法成本低，且语义清晰
如果只是封装一个 open() 或 requests.session()，用 @contextmanager 写三行更直白
@contextmanager 函数里不能用 return 提前退出，否则上下文无法正常结束；必须用 yield，且 yield 后代码才是 __exit__ 阶段