__enter__必须是实例方法，若误用@classmethod或@staticmethod会导致TypeError；它抛异常时__exit__仍会执行，且三参数非空，用于清理部分资源。
为什么直接在类方法里写 __enter__ 会失效
因为 __enter__ 必须是实例方法（且不能带额外参数），如果误把它写成 @classmethod 或 @staticmethod，with 语句调用时会报 TypeError: __enter__() takes 1 positional argument but 2 were given——这是 Python 把实例自动传给第一个参数时发现签名不匹配导致的。
常见错误还包括：把 __enter__ 定义在父类但子类没显式继承，或用了 self 却忘了声明为实例方法。
__enter__ 中抛异常后 __exit__ 还会执行吗
会。只要 __enter__ 抛出异常，__exit__ 仍会被调用，且此时三个参数 exc_type、exc_value、traceback 都非 None。这是设计使然：资源初始化失败时，__exit__ 可能要清理已分配的部分资源（比如打开了一半的文件句柄、已申请的内存块）。
- 若
__enter__中open()失败，可在__exit__里检查self._file是否为None再决定是否.close() - 不要在
__enter__里吞掉异常（如except: pass），否则with块根本不会进入，__exit__也不会被触发 -
__exit__返回True才能抑制异常；返回None或False会让异常继续向上冒泡
如何让 __enter__ 支持“部分成功”状态并透出错误细节
典型场景是连接数据库或 HTTP 客户端：认证通过但后续权限校验失败。这时不应直接 raise，而应把错误信息存到实例属性，交由 __exit__ 统一处理或由使用者在 with 块内检查。
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
def __enter__(self):
try:
self._conn = connect(self.host)
self._auth_ok = True
except ConnectionError as e:
self._init_error = e
self._auth_ok = False
# 不 raise，让 with 块继续执行，使用者可主动检查
return self
<p>def <strong>exit</strong>(self, *args):
if hasattr(self, '_conn') and self._conn:
self._conn.close()
if self._init_error:</p><h1>可选择在此 re-raise，或记录日志</h1><pre class="brush:php;toolbar:false;"><code> raise self._init_error
注意：这种模式要求使用者明确检查 obj._auth_ok 或类似状态位，否则容易忽略初始化失败却继续调用方法。
重写 __enter__ 时最容易被忽略的兼容性点
Python 3.11+ 引入了 ExceptionGroup 和 BaseExceptionGroup，如果 __enter__ 内部使用了 asyncio.gather(..., return_exceptions=True) 或其他可能抛出异常组的逻辑，需确保 __exit__ 能正确处理 exc_type 是 ExceptionGroup 的情况。
- 老代码中常写
if exc_type is not None:，这在遇到ExceptionGroup时依然成立，但后续isinstance(exc_value, SomeError)可能失效 - 推荐用
if exc_type and not isinstance(exc_value, BaseException):做兜底判断 - 若上下文管理器本身被用于
async with，则必须实现__aenter__/__aexit__，__enter__完全不生效
重写 __enter__ 看似简单，但异常传播路径、状态残留、异步/同步混用这几处，稍不留意就会让资源泄漏或掩盖真实错误。
