Python 异步上下文管理器的实现

async with 语句要求对象必须同时实现 __aenter__ 和 __aexit__ 两个异步方法，前者返回可 await 对象，后者接收四个参数并可选抑制异常，二者缺一不可。

async with 语句要求对象实现哪些方法

必须同时提供 __aenter__ 和 __aexit__ 两个异步方法，缺一不可。python 在执行 async with obj: 时会按顺序 await 这两个方法，而不是普通同步的 __enter__/__exit__。

常见错误是只实现了其中一个，导致运行时报错：AttributeError: __aexit__ not found 或 SyntaxError: 'async with' requires an Object with __aenter__ and __aexit__。

• __aenter__ 应返回一个可 await 的对象（通常用 return self 或 return await something()）
• __aexit__ 必须带四个参数：(self, exc_type, exc_value, traceback)，且返回值应为 bool 类型（用于抑制异常），或直接不写 return（等价于 return None）
• 不能在 __aenter__ 或 __aexit__ 中使用 yield —— 那是异步生成器的写法，不是上下文管理器所需

如何正确释放异步资源（比如网络连接）

典型场景是封装一个需要 await 关闭的客户端，例如基于 aiohttp 或自定义 TCP 连接。关键点在于：清理逻辑本身也得是异步的，不能塞进同步的 __exit__。

错误示范：def __exit__(self, ...): self._conn.close() —— 这里 close() 若是协程，不 await 就等于没调用；若它是同步方法，则可能漏掉底层异步关闭步骤（如等待 FIN-ACK）。

立即学习“Python免费学习笔记（深入）”；

• 所有资源释放操作必须放在 __aexit__ 内，并显式 await
• 建议在 __aexit__ 开头加 if self._closed: 判断，避免重复关闭
• 若 __aenter__ 中初始化失败（比如 await connect() 抛异常），__aexit__ 仍会被调用，此时需检查资源是否已创建，否则可能触发 AttributeError

与同步上下文管理器共存时的陷阱

一个类如果既想支持 with 又想支持 async with，不能简单地让 __aenter__ 调用 __enter__，反之亦然。因为它们的调用协议和生命周期不同。

更常见的需求其实是「兼容两种写法」，但实际中应避免这种设计：它容易掩盖阻塞风险（比如在 async with 块里误用同步 I/O）。

• 不要在 __aenter__ 中直接 return self.__enter__() —— 返回的是普通对象，不是协程，async with 会报 TypeError: unawaitable
• 若真要复用逻辑，把初始化/清理抽成独立的 async 方法（如 async def open(self) / async def close(self)），再由 __aenter__/__aexit__ 调用它们
• 同步版本保持原样，不依赖异步方法；二者逻辑应隔离，避免交叉 await

测试异步上下文管理器是否生效

最直接的方式是写个最小 async 函数，用 async with 包裹后观察行为，重点验证两点：进入时是否完成初始化、退出时是否真正 await 了清理。

别只测“不崩溃”，要确认副作用发生。例如打开文件描述符后检查 os.listdir('/proc/self/fd')（linux），或打日志看 __aexit__ 是否被 await 执行。

• 用 pytest + asyncio.run() 或 @pytest.mark.asyncio 运行测试函数
• 在 __aexit__ 里故意 raise 异常，观察是否被外层捕获 —— 可验证返回值是否影响异常传播
• 若管理器内部用了 asyncio.Lock 或类似资源，记得在测试前后检查锁状态，避免假阴性

异步上下文管理器的难点不在语法，而在对资源生命周期的精确控制：每个 await 都是调度点，每个未 await 的协程调用都是潜在的泄漏源。最容易被忽略的是 __aexit__ 中对 exc_type 的处理 —— 很多人直接忽略它，结果异常吞没后调试困难。