__exit__ 返回 True 会抑制异常，因其向 Python 表明“异常已被处理”；需显式返回 False 或不返回以传播异常，且必须兼容 exc_type=None 的正常退出场景。
直接说结论：用 __enter__ 返回资源对象，__exit__ 处理清理和异常，就能让类支持 with 语句——但漏掉 __exit__ 的返回值逻辑，会导致异常被吞掉。
为什么 __exit__ 返回 True 会吃掉异常？
__exit__ 接收三个参数：exc_type、exc_value、traceback。只要它最终返回布尔值 True，Python 就认为“这个异常已被处理”，不再向上抛出。
- 常见错误：在日志记录后忘了加
return False，结果本该崩溃的代码静默失败 - 正确做法：只在你**明确想压制某类异常**时才返回
True，比如忽略OSError中的“文件不存在” - 默认行为：不写
return或返回None/False，异常照常传播
__enter__ 返回什么，决定了 as 后面接什么
with MyContext() as x: 这里的 x 就是 __enter__ 的返回值。它不一定要是 self，可以是任意对象。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 返回
self：适合需要链式调用或多次访问属性的场景，比如数据库连接类 - 返回内部资源：比如打开的文件句柄、临时目录路径，避免用户误操作
self - 返回
None：如果上下文本身不提供可交互对象（如计时器、锁），就别配as，直接with MyTimer():
手动触发 __exit__ 的典型错误场景
有人会在 __enter__ 抛异常，以为 __exit__ 会被调用——但不会。只有 __enter__ 成功返回后，__exit__ 才保证执行。
立即学习“Python免费学习笔记（深入）”；
- 资源获取失败（如端口被占）应直接 raise，不要指望
__exit__清理未创建的资源 - 真正需要提前清理的逻辑，得放在
__enter__内部的try/finally里 - 若
__exit__自身抛异常，会替代原始异常（除非原始异常是SystemExit或KeyboardInterrupt）
最易被忽略的是：__exit__ 必须能处理 exc_type 为 None 的情况（即 with 块正常退出），这时候你不能假设三个参数都有值，否则 AttributeError 会悄悄冒出来。
