__enter__ 和 __exit__ 由 Python 解释器在 with 语句进入和退出时自动调用：前者返回值绑定 as 变量，后者接收异常三元组并决定是否吞掉异常；即使 __enter__ 抛异常，__exit__ 也不会被调用。
__enter__ 和 __exit__ 是怎么被调用的
Python 的 with 语句不是语法糖，而是有明确的协议调用逻辑：进入 with 块时自动调用对象的 __enter__ 方法，退出时（无论是否异常）必定调用 __exit__ 方法。这个过程由解释器底层控制，不依赖装饰器或手动触发。
关键点在于：__enter__ 的返回值会绑定到 as 后的变量；__exit__ 必须接收三个参数：exc_type、exc_value、traceback，哪怕你用不到也得声明。
-
__enter__可以返回任意对象（包括self），但若返回None，as绑定会出错：AttributeError: __enter__ returned None -
__exit__返回True表示“已处理异常”，解释器将不再向上抛；返回False或None则原异常继续传播 - 即使
__enter__抛异常，__exit__也不会被调用 —— 这是常见误区
手写上下文管理器时容易漏掉的兼容性细节
自己实现 __enter__/__exit__ 时，最常忽略的是对多重退出路径的支持：比如 return、break、continue、未捕获异常、系统信号中断等。只要控制流离开 with 块，__exit__ 就必须执行。
另一个易错点是资源清理顺序：如果 __enter__ 中开了多个资源（如文件 + 网络连接），而其中某个初始化失败，__exit__ 里不能盲目释放所有资源 —— 需要记录哪些已成功创建。
立即学习“Python免费学习笔记（深入）”；
- 建议在
__init__中把资源设为None，只在__enter__中成功创建后才赋值 -
__exit__开头加守卫判断：if self.file is not None:再做.close() - 避免在
__exit__中抛新异常；若清理过程可能出错，应捕获并记录日志，而不是让异常覆盖原始错误
@contextlib.contextmanager 装饰器和类实现的区别
用 @contextlib.contextmanager 写上下文管理器本质是生成器函数，它把 yield 之前的代码当 __enter__，之后当 __exit__。但它的异常传播行为和类实现不同：一旦 yield 后代码抛异常，该异常会被解释器捕获并作为 exc_type 等参数传回同一函数内部（即 yield 行本身会重新抛出异常）。
from contextlib import contextmanager <p>@contextmanager def managed_file(name): f = open(name, 'w') try: yield f # ← 这里交出控制权，with 块执行 finally: f.close() # ← 不管上面是否异常，这里都会运行</p>
- 类实现更透明、可继承、支持状态保存；装饰器写法简洁，但调试时堆栈不易追踪
-
@contextmanager函数不能接受self，所以无法直接用于实例方法 —— 若需绑定实例状态，仍得用类 - 装饰器方式下，
yield表达式的值就是as绑定的对象；若yield不带值（即yield单独一行），则绑定为None
嵌套 with 语句中 __exit__ 的调用顺序
多个 with 嵌套时，__exit__ 按「后进先出」逆序调用，和栈一致。这决定了资源释放顺序：最内层最先退出，最外层最后退出。
例如打开文件再加锁，通常希望先释放锁再关文件，那就得把锁放在外层 with，文件放在内层；反过来就会出现「文件已关但锁还占着」的风险。
- 嵌套中任一
__exit__返回True，只会吞掉当前层级的异常，不影响外层对异常的处理 - 若外层
__exit__返回True，内层异常不会传播到最外作用域，但内层自己的__exit__仍会被调用（因为退出动作已发生） - 不要依赖嵌套顺序做业务逻辑判断 —— 显式用变量标记状态更可靠
实际用的时候，最容易被忽略的是 <strong>exit</strong> 的参数判空逻辑：比如想忽略 FileNotFoundError，得写 if exc_type is not FileNotFoundError:，而不是 if exc_type != FileNotFoundError: —— 因为异常类是类型对象，不是字符串。
