Python异步编程中的异常处理远比同步代码复杂且隐蔽：asyncio.run()会将原始异常包装为RuntimeError，需手动检查__cause__或__context__才能还原真相；未await的Task异常会被静默吞没，导致后台任务崩溃却毫无提示；gather默认遇错即停，而wait则需手动遍历检查结果；async with和async for更易因__aexit__/__annext__中的异常掩盖业务错误。掌握这些“反直觉”的传播机制与实操技巧，是写出健壮、可调试、真正可靠的异步代码的关键防线。

asyncio.run() 里抛出的异常为什么没被 try 捕获

因为 asyncio.run() 会把协程里未处理的异常包装成 RuntimeError 并重新抛出，但原始异常藏在 __cause__ 或 __context__ 里，直接 except Exception: 看不到它的真实类型和 traceback。

实操建议：

• 用 try/except 包裹 asyncio.run() 后，检查 exc.__cause__（显式链式异常）或 exc.__context__（隐式传播），再 raise 原始异常
• 更稳妥的做法是别让异常跑到 asyncio.run() 外层——在主协程里就 try/except，手动处理或 logging.exception()
• 注意：asyncio.run() 内部调用 loop.run_until_complete()，而后者对未捕获异常的行为是“原样抛出”，但顶层封装加了一层包装

import asyncio
async def bad():
raise ValueError("boom")
try:
asyncio.run(bad())
except RuntimeError as e:
if e.cause:
raise e.cause  # 这样才能拿到 ValueError
raise

Task 对象里的异常不会自动冒泡

用 asyncio.create_task() 启动的任务，如果内部出错且没被 await，异常会被静默吞掉，只在任务对象的 exception() 方法里保留，不会中断主线程，也不会触发任何日志。

常见错误现象：程序看似正常退出，但某个后台任务其实已崩溃，且毫无提示。

实操建议：

• 所有 create_task() 后，要么 await task，要么在合适时机调用 task.exception() 主动检查
• 避免用 asyncio.ensure_future() 替代 create_task() 来“隐藏”任务——两者行为一致，只是 API 层级不同
• 若任务是“火起来就不管”的（如心跳上报），至少加一层 try/except + logging.error()，别依赖外部捕获

await gather() 和 wait() 的异常行为差异

asyncio.gather() 默认遇到第一个异常就中止所有并发任务并抛出；asyncio.wait() 则默认不抛异常，得自己遍历 done 集合调用 task.exception()。

使用场景：需要“全量执行+汇总错误”时，gather(return_exceptions=True) 更省心；需要“按完成顺序处理+容错继续”时，wait() 更可控。

实操建议：

• 用 gather() 时，明确传 return_exceptions=True，之后用 isinstance(exc, Exception) 过滤结果列表
• wait() 不会自动 await 任务，返回的是 (done, pending)，记得对 done 中每个 task 调用 task.result() 或 task.exception()
• 性能影响：两者底层都走事件循环调度，无实质差异；但 gather() 在异常传播逻辑上更重，有额外的包装开销

import asyncio
async def maybe_fail(n):
if n == 2:
raise ValueError("failed at 2")
return n * 2
gather 默认会停在第一个异常
try:
res = await asyncio.gather(maybe_fail(1), maybe_fail(2), maybe_fail(3))
except ValueError as e:
print("got", e)  # 只会看到 "failed at 2"
改成 return_exceptions=True 就能拿到全部结果（含异常对象）
res = await asyncio.gather(
maybe_fail(1), maybe_fail(2), maybe_fail(3),
return_exceptions=True
)
for r in res:
if isinstance(r, Exception):
print("error:", r)
else:
print("ok:", r)

async with 和 async for 里的异常传播容易漏处理

异步上下文管理器（async with）和异步迭代器（async for）在 __aexit__ 或 __anext__() 抛异常时，可能掩盖原始业务异常。比如 __aexit__ 里又抛新异常，就会覆盖 with 块里的异常。

容易踩的坑：以为 async with 跟同步 with 行为完全一致，忽略了 __aexit__ 的返回值逻辑——返回 True 会抑制异常，但大多数异步库（如 aiohttp、aiomysql）的 __aexit__ 不返回 True，所以通常不会抑制，但自定义实现时容易写错。

实操建议：

• 不要在 async with 块内做可能失败的清理操作；清理逻辑应放在 __aexit__ 里，并确保它不抛异常，或用 try/except 吞掉自身异常
• 用 async for 时，异常可能来自 __anext__()（数据获取失败）或迭代体内部（业务逻辑错误），需统一用外层 try/except 包裹整段循环
• 调试时可临时给自定义异步上下文管理器的 __aexit__ 加 print(repr(exc_type))，确认它是否真的收到了原始异常

异常传播链条比同步代码长一截，从协程帧到 Task 对象再到事件循环，中间任何一环没显式处理，就容易断在看不见的地方。最常被忽略的是：你以为 await 一个 task 就等于“接管了它的异常”，其实没 await 的 task 异常根本不会浮现。

本篇关于《Python异步异常处理方法详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！