@contextmanager 更轻量是因为它用生成器函数替代类定义，仅创建轻量的_GeneratorContextManager实例，避免类实例化开销；默认异常传播行为是yield后异常传给__exit__处理并向上冒泡；嵌套损耗在于生成器切换和__exit__调用链；适用场景限于简单同步无状态逻辑，复杂需求应回归类实现。
为什么 @contextmanager 比手写 __enter__/__exit__ 更轻量？
因为 @contextmanager 把上下文逻辑压进一个生成器函数里，省掉类定义、实例化、属性绑定这些开销。它不创建新类对象，只在调用时生成一个 _GeneratorContextManager 实例——这个实例几乎只存一个函数引用和参数元组。
- 手写类要定义两个方法 + 可能的
__init__，每次with都 new 一个实例 -
@contextmanager的装饰器返回对象是单例模式复用的（内部缓存），且生成器暂停/恢复比方法调用更省内存 - 注意：生成器函数本身不能有
return值（除了return或return None），否则会抛RuntimeError: generator didn't yield
@contextmanager 中异常传播的默认行为是什么？
它默认把进入后（yield 后）发生的异常原样传给 __exit__ 处理，并且如果生成器函数没捕获该异常，@contextmanager 会自动让它继续向上冒泡——这和手动写的上下文管理器行为一致，但容易误以为“yield 后的代码能兜住异常”。
-
yield之前出错 → 不进with块，__exit__不触发 -
yield之后出错 → 异常被传入__exit__(exc_type, exc_value, traceback)，若函数内没try/except，异常照常抛出 - 想吞掉异常？必须在生成器里
try/except包住yield后的逻辑，并在except末尾return True
嵌套多个 @contextmanager 时性能损耗在哪？
不是嵌套本身慢，而是每层都多一次生成器状态切换 + 多一层 __exit__ 调用链。Python 的生成器切换开销虽小，但在高频循环（比如每毫秒进一次 with）里会明显放大。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 避免在 tight loop 里反复进
with，改用单次上下文包裹整个循环体 - 不要为了“看起来整洁”而把本可合并的资源管理拆成多个
@contextmanager（比如文件打开 + 编码转换 + 行过滤，能合就合） - 如果只是做简单的资源标记（如计时、日志开关），直接用
contextlib.nullcontext()，零开销
什么时候该放弃 @contextmanager，回头写类？
当上下文需要保存状态、支持多次重入、或要兼容 async with 时，@contextmanager 就不够用了——它本质是同步生成器，没法 await，也不支持 __enter__ 返回不同实例。
立即学习“Python免费学习笔记（深入）”；
- 要支持异步？必须实现
__aenter__和__aexit__，用async def写，@contextmanager完全不适用 - 需要线程安全的重入？类可以加
threading.RLock，而生成器函数每次调用都是新状态，无法共享锁 - 想让同一个上下文管理器实例被多次
with使用（比如全局 logger 控制器）？类可以控制__enter__返回self，@contextmanager每次都新建生成器对象
生成器式上下文管理器很省事，但它的“轻量”是有前提的：逻辑简单、无状态、纯同步。一旦边界模糊，类反而更可控。
