asyncio.run()中协程抛异常只警告不报错，因其默认异常处理器仅发出RuntimeWarning；需手动创建事件循环并设置set_exception_handler才能转为错误终止程序。
asyncio.run() 里协程抛异常为什么只警告不报错
因为 asyncio.run() 内部用 asyncio.ensure_future() 启动主协程，而未被 await 的任务（比如子任务里抛了异常但没人 catch）会触发 asyncio.exceptions.CancelledError 或普通异常未处理，最终由事件循环在关闭前调用 loop.set_exception_handler() 默认处理器——它只是发个 RuntimeWarning: coroutine 'xxx' was never awaited 或 Exception in callback ... 警告，不中断程序。
用 loop.set_exception_handler 拦截并转为错误
必须在事件循环启动前设置自定义异常处理器，且要覆盖默认行为。注意：不能在 asyncio.run() 内部设（它会重置 loop），得用底层 API 手动管理 loop：
import asyncio
import sys
<p>def custom_exception_handler(loop, context):</p><h1>context 至少包含 'exception' 或 'message' 键</h1><pre class="brush:php;toolbar:false;">exc = context.get("exception")
if exc is not None:
# 直接抛出，让进程退出（或按需记录/发送告警）
sys.exit(f"Uncaught asyncio exception: {exc}")
else:
sys.exit(f"Asyncio unhandled context: {context.get('message', '')}")loop = asyncio.new_event_loop() loop.set_exception_handler(custom_exception_handler) asyncio.set_event_loop(loop)
try: loop.run_until_complete(main()) finally: loop.close()
- 必须在
run_until_complete()前调用loop.set_exception_handler() -
context["exception"]是实际异常对象；若为None，说明是回调执行失败等非异常上下文 - 直接
sys.exit()最干脆；若需继续运行，可改用logging.error()+raise
避免警告的常见漏网场景
有些异常根本不会进 set_exception_handler，而是直接触发 RuntimeWarning，比如：
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 协程对象被创建但完全没被
await或ensure_future()—— 这属于语法误用，不是运行时异常，set_exception_handler不管 - 在
async with或async for中，__aenter__/__aexit__抛异常但未被上层捕获，可能绕过主 task 异常路径 - 使用
asyncio.create_task()后忘记await task或task.exception()检查，异常会静默丢失
这类问题得靠静态检查（如 pylint 的 unnecessary-await / unused-variable）和代码审查，运行时无法统一拦截。
测试时强制暴露未处理异常
开发阶段可以用环境变量或 pytest 配置让警告变成错误，提前发现问题：
import warnings
warnings.filterwarnings("error", category=RuntimeWarning, module="asyncio")
这样一旦出现 "coroutine 'xxx' was never awaited" 就直接抛 Warning 异常，而不是打印警告。
真正难防的是那些“看似 await 了、实则被 cancel 掉后异常吞掉”的情况——比如 asyncio.wait_for(task, timeout) 超时后 task 被 cancel，其内部异常就再也不会浮现。这种必须靠 task 完成后显式调用 task.exception() 检查。
