asyncio.run()在Jupyter或FastAPI中必报错，因其设计强制新建并关闭事件循环，而这些环境已运行长期loop，检测到运行中loop即抛RuntimeError；应改用await、create_task或get_running_loop()。
asyncio.run() 会强制关闭并替换当前线程的事件循环，而 Python 不允许一个线程存在多个运行中的事件循环
为什么 asyncio.run() 在 Jupyter 或 FastAPI 里必报错
IPython 内核、FastAPI、Django Channels 等环境启动时已调用 loop.run_forever()，整个线程处于一个长期运行的事件循环中。asyncio.run() 的设计是“新建 → 运行 → 关闭”完整生命周期，它内部会调用 asyncio.get_event_loop() 检查——只要检测到已有运行中的循环，就直接抛出 RuntimeError: asyncio.run() cannot be called from a running event loop。
这不是 bug，是硬编码限制：避免循环嵌套、资源泄漏、任务调度错乱。你无法通过参数绕过，也无法用 try/except 捕获后继续运行。
在已有 loop 的环境里该用什么替代
核心原则：不重启 loop，只往现有 loop 里提交任务。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
- 在 Jupyter 或 async 函数内部，直接
await coro()—— 最简单，也最安全 - 需要从同步上下文“挤进去”（比如 Flask 视图），用
asyncio.get_event_loop().create_task(coro())（Python 3.7+） - 若当前线程确实没有运行中的 loop（如普通脚本或子线程），才可用
asyncio.new_event_loop()+loop.run_until_complete()，但必须手动管理 loop 生命周期 - 第三方库如
nest_asyncio是补丁方案，仅用于开发调试；它重写了run()的检测逻辑，但不解决根本问题，生产环境禁用
常见误操作与静默失败点
很多错误不是立刻报错，而是逻辑跳过或结果丢失：
- 写
fetch(url)却没加await，返回的是<coroutine object ...>，传给asyncio.run()后仍触发嵌套检测（因为协程对象本身不含 loop 状态，但run()调用时才检查） -
asyncio.gather(coro, coro)中重复传入同一个协程对象，报RuntimeError: cannot reuse already awaited coroutine，和 loop 嵌套无关，但常被混淆 - 在
__del__、atexit或 logging handler 中调用异步逻辑——这些上下文无可靠事件循环，get_running_loop()直接失败 - 多线程中混用
asyncio.run()和asyncio.get_event_loop()，不同线程的 loop 不互通，容易出现There is no current event loop in thread 'XXX'
真正难处理的不是报错本身，而是那些没报错却没执行的协程——它们只是被创建，然后被垃圾回收。检查 type(obj) 是否为 asyncio.Coroutine，比看日志更早发现问题。
