__aexit__ 无条件执行且必须 await 异步清理，确保异常、return 或 break 时均释放资源；需用 if exc_type is not None 判断异常，避免阻塞事件循环，返回 False（或 None）以传播原始异常。
它靠 __aexit__ 无条件执行，且必须用 await 做异步清理 —— 同步调用或漏写 await 就会卡住事件循环、导致资源泄漏。
为什么 __aexit__ 能保证异常时也执行
只要进入 async with 块，无论中间是 return、break 还是抛出未捕获异常，解释器都会在退出时调用 __aexit__。这个行为由 Python 运行时强制保障，不依赖用户手动控制。
常见错误现象：
- 把清理逻辑写在
try/except里，却忘了在except和else中都调用关闭逻辑 - 误以为
__aexit__只在异常时触发，结果正常退出时资源没释放
__aexit__ 参数怎么用才不踩坑
exc_type、exc_value、traceback 三者全为 None 表示无异常；只要任一非 None，就说明发生了异常。别直接判 if exc_value: —— 某些异常（如 SystemExit）的 exc_value 可能为 None，但 exc_type 不为空。
立即学习“Python免费学习笔记（深入）”；
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
使用建议：
- 用
if exc_type is not None:判断是否发生异常 - 记录日志时优先用
repr(exc_value)，避免str(exc_value)在某些异常下返回空字符串 - 不要在
__aexit__里raise新异常，否则会覆盖原始异常；真要处理，应return True显式抑制，或用raise+from exc_value链式抛出
异步清理必须 await，不能“假装异步”
很多初学者在 __aexit__ 里调用同步方法（比如 self.sock.close()），表面看不报错，实则阻塞事件循环 —— 因为该方法可能内部还在做系统调用或等待内核状态。
正确做法：
- 确认所用库是否提供真正异步的关闭接口：如
aiohttp.ClientSession的close()是协程，而原生socket.close()不是 - 若底层只提供同步接口，需用
loop.run_in_executor包装，但要注意线程安全和 executor 负载 - 永远检查文档：例如
asyncpg.Connection的close()是协程，但terminate()才是立即释放，二者语义不同
返回值决定异常是否传播，别默认 return True
__aexit__ 返回 True 会吞掉异常，后续代码看不到它。这在需要统一兜底处理时有用，但绝大多数场景应该返回 False 或不写 return（Python 默认返回 None，等价于 False）。
容易被忽略的地方：
- 如果清理过程自己抛了新异常（比如
await conn.close()时网络断开），这个新异常会取代原始异常向上冒泡 —— 原始错误信息就丢了 - 想同时记录原始异常又确保清理完成，得把清理逻辑包在
try/except内部，且不能让清理异常干扰主异常传播 - 测试时务必覆盖「业务代码抛异常」+「清理过程也失败」双失败路径，这是资源泄漏最高发的盲区
