Python上下文管理器需实现__enter__和__exit__方法，前者返回资源，后者接收三个异常参数并负责清理；@contextlib.contextmanager可简化实现，用yield分割进入与退出逻辑。
用 __enter__ 和 __exit__ 手动实现上下文管理器
Python 的 with 语句依赖对象实现两个特殊方法：__enter__ 返回进入上下文时的值（比如打开的文件），__exit__ 负责清理——无论是否发生异常都必须执行。手动实现时，__exit__ 的三个参数（exc_type、exc_value、traceback）不能忽略，哪怕只写 pass 也得接收它们，否则会报 TypeError: __exit__() takes 1 positional argument but 4 were given。
常见错误是忘记在 __exit__ 中返回 True 来抑制异常——这仅在你明确想吞掉异常时才做；多数情况下应让异常继续冒泡，靠外层处理。
示例：一个简单的文件包装器
class ManagedFile:
def __init__(self, name):
self.name = name
self.file = None
<pre class="brush:php;toolbar:false;">def __enter__(self):
self.file = open(self.name, 'w')
return self.file
def __exit__(self, exc_type, exc_value, traceback):
if self.file:
self.file.close()
# 不返回 True，异常正常传播
立即学习“Python免费学习笔记（深入）”；
使用时：
with ManagedFile('test.txt') as f:
f.write('hello')
# 离开 with 块后，文件已关闭
用 @contextlib.contextmanager 装饰器简化实现
比起手写双下划线方法，@contextlib.contextmanager 更轻量、更符合直觉：函数里用 yield 分割“进入”和“退出”逻辑，yield 之前的代码相当于 __enter__，之后的相当于 __exit__（在 finally 块中执行）。
注意点：
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
-
yield必须出现且只能出现一次，否则装饰器会报错 - 如果想捕获并处理异常，得在
yield后加try/except/finally，但不要在except里重新抛出——那会干扰上下文管理器对异常传播的控制 - 函数体中不能有多个
return干扰控制流
示例：带日志的数据库连接管理
from contextlib import contextmanager
<p>@contextmanager
def db_connection(url):
conn = None
try:
print("Connecting...")
conn = connect_to_db(url) # 假设存在该函数
yield conn
finally:
if conn:
print("Closing connection...")
conn.close()
调用方式不变：with db_connection('sqlite:///app.db') as conn:
资源未释放的典型表现与排查线索
上下文管理器失效时，往往不是立刻报错，而是表现为“资源泄漏”：文件句柄耗尽（OSError: [Errno 24] Too many open files）、数据库连接池打满、网络 socket 处于 CLOSE_WAIT 状态等。
容易被忽略的坑：
- 在
__enter__中抛异常 →__exit__根本不会被调用 → 资源没创建成功，自然谈不上释放，但你可能误以为“没进 with 就安全了” - 用了
break/return/sys.exit()提前跳出with块 → 不影响__exit__执行，这是设计保障；但若在__exit__内部又抛新异常，则可能掩盖原始异常 - 多线程环境下共享同一个上下文管理器实例 →
__exit__可能被并发调用，需自行加锁或避免共享实例
何时不该用上下文管理器？
上下文管理器本质是“确定性生命周期”的抽象。如果资源的释放时机不取决于代码块边界（比如要跨函数、跨回调、或由外部事件触发），硬套 with 反而会让逻辑扭曲。
典型反例：
- 全局配置对象，初始化一次、整个进程生命周期内复用，不需要每次
with - 异步 I/O（如
asyncio中的async with是另一套机制，普通同步上下文管理器无法直接用于await表达式） - 资源释放依赖用户交互（如 GUI 中点击“关闭”才释放），这时更适合显式调用
.close()或信号绑定
真正关键的不是“用了 with”，而是“释放逻辑是否严格绑定在作用域退出那一刻”。漏掉这个判断，再漂亮的语法也救不了泄漏。
