asyncio异常被吞因未await或检查task状态，需用set_exception_handler自定义处理、gather(return_exceptions=true)保留堆栈、为task设name定位源头。
asyncio 异常被吞掉，print_exc() 也不显示？
异步任务里抛出的异常如果不显式 await 或检查 Task 状态，大概率会静默消失——不是没发生，而是被 asyncio 默认吃掉了。典型现象是：程序没报错、也没按预期执行，日志里空空如也。
关键原因在于：未被 await 的协程对象（或调用 create_task() 后放任不管）一旦出错，只会在事件循环结束时打印一条 Exception ignored in: ...，且堆栈极短，根本定位不到源头。
- 务必对所有
create_task()返回的Task对象做显式处理：要么await task，要么在合适时机调用task.exception()检查 - 开发期可临时启用严格模式：
asyncio.get_event_loop().set_exception_handler()，自定义 handler 中打印完整 traceback - 避免直接调用协程函数却不 await：
my_coro()是个协程对象，不是执行；漏掉await就等于“注册但不运行”，错误自然无处落脚
如何让 asyncio 报错时打出完整堆栈？
默认的异常处理太“温柔”，得手动撬开它的日志盖子。核心思路是接管异常分发，把原始 traceback 塞进标准错误流，而不是等它被丢弃。
最简生效方式是在启动前加一段钩子：
import asyncio
import traceback
def custom_exc_handler(loop, context):
if 'exception' in context:
traceback.print_exception(type(context['exception']), context['exception'], context['exception'].__traceback__)
else:
loop.default_exception_handler(context)
loop = asyncio.get_event_loop()
loop.set_exception_handler(custom_exc_handler)
- 这个 handler 能捕获
Task内未处理异常、call_soon()回调错误、甚至asyncio.sleep()被 cancel 时的CancelledError - 注意：不要在 handler 里再 await 任何协程——此时事件循环可能已关闭或不稳定
- 生产环境慎用裸
print_exception，建议改用logging.error(..., exc_info=True)
asyncio.gather() 和 asyncio.wait() 的错误行为差异
这两个常用并发组合子对异常的处理逻辑完全不同，选错就等于主动放弃堆栈线索。
gather() 默认“快速失败”：只要一个子任务出错，整个调用就 raise 该异常，但原始 traceback 会被截断——你看到的是 gather 自己抛的，不是子任务里的。
wait() 则更“沉默”：异常全藏在完成的 Task 对象里，不主动暴露。
- 要保留原始堆栈，用
gather(..., return_exceptions=True)，然后遍历结果，对每个isinstance(x, Exception)的项单独raise x - 用
wait()时，必须手动遍历done集合，对每个task.exception()做非空检查并处理 - 别依赖
except Exception:包住整个gather()调用——它拦不住内部 Task 的静默崩溃
调试时怎么快速定位是哪个 Task 在报错？
当有十几个 Task 并发跑着，光看堆栈根本分不清谁干的。得给它们“贴标签”。
最有效的方式是创建时传入 name 参数，并在异常 handler 里一并打印：
task = asyncio.create_task(my_coro(), name="fetch_user_123")
然后在自定义 custom_exc_handler 里加一句：print("Task:", context.get('task'), "raised:", context['exception'])。
-
name必须是字符串，支持任意标识，比如用户 ID、请求路径、时间戳片段 - 不设
name时，task.get_name()返回默认名（如Task-32），毫无业务意义 - 如果用
asyncio.to_thread()或loop.run_in_executor()，异常会包装成concurrent.futures.CancelledError或BrokenProcessPool，需额外判断__cause__
异步堆栈不像同步那样线性可读，真正麻烦的不是找不到错，而是错被转手了三四次才露面——从 Task 到 loop handler，再到 gather 包装，最后落到你 catch 的位置。每转一次，原始上下文就薄一层。盯紧 name 和 __cause__，比猜 traceback 更可靠。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
