asyncio.run() 禁止嵌套调用，因它要求顶层干净事件循环；在已有运行 loop 的环境（如 Jupyter、Web 框架）中会报 RuntimeError；应改用 asyncio.create_task() 提交任务而非重启 loop。
asyncio.run() 会检查并拒绝嵌套事件循环
因为 asyncio.run() 内部会调用 asyncio.get_event_loop()，如果当前线程已有运行中的事件循环（比如在 Jupyter、Django Channels、或已手动调用 loop.run_until_complete() 的上下文中），它就会抛出 RuntimeError: asyncio.run() cannot be called from a running event loop。
这不是 bug，而是设计使然：它强制“一个顶层协程、一个干净事件循环”的语义，避免循环嵌套、资源泄漏和调度混乱。
- 常见触发场景：在 Jupyter notebook 单元格里反复执行
asyncio.run()；在 Flask/Gunicorn 进程中每次请求都调用它；在已启动的asyncio.EventLoop中又调用它 - 它不尝试复用现有 loop，也不支持配置是否允许嵌套——行为是硬编码拒绝
- 底层实际调用了
loop.close()和asyncio.set_event_loop(None)，所以强行在已有 loop 中运行会导致状态不一致
替代方案：用 ensure_future() 或 create_task() 手动提交协程
当事件循环已在运行时，正确做法是获取当前 loop 并提交任务，而不是重启 loop。
例如，在 Jupyter 或异步 Web 框架中：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
立即学习“Python免费学习笔记（深入）”；
import asyncio <h1>✅ 正确：复用当前 loop</h1><p>loop = asyncio.get_running_loop() task = loop.create_task(some_coroutine())</p><h1>或更简洁地（Python 3.7+）</h1><p>task = asyncio.create_task(some_coroutine())
-
asyncio.create_task()是首选，它隐式调用当前运行 loop 的create_task()，且比ensure_future()更明确语义 - 不要用
loop.run_until_complete()—— 它会阻塞当前线程，破坏异步上下文（比如在 FastAPI 路由里这么写会导致整个服务器卡住） - 注意任务生命周期：若协程返回后你没 await 或检查结果，可能静默失败；建议配合
asyncio.wait()或asyncio.gather()管理多个任务
为什么不能简单 patch loop 或设 allow_nested=True？
Python 标准库没有提供类似 allow_nested=True 的参数，也不是遗漏——嵌套事件循环本身在 asyncio 设计哲学中就是反模式。
- 事件循环是线程级单例资源，多层 loop 带来调度优先级、异常传播、取消信号（
asyncio.CancelledError）传递等不可靠行为 - 某些第三方库（如
nest_asyncio）确实打了补丁，但它通过 monkey patch 修改asyncio.run()和 loop 启动逻辑，本质是绕过校验，不是标准解法 - 如果你真需要“隔离”协程执行环境，应该用
asyncio.new_event_loop()+loop.run_until_complete()在新线程中运行，而不是在同一线程嵌套
调试时如何快速判断是否已有运行中的 loop？
最直接的方式是捕获异常并检查，但更主动的做法是加一行诊断：
try:
loop = asyncio.get_running_loop()
print(f"Running loop: {loop}")
except RuntimeError:
print("No running loop")
-
asyncio.get_running_loop()是唯一可靠方式；asyncio.get_event_loop()可能返回未运行的 loop，误导判断 - Jupyter 默认启动 loop，但只在 kernel 启动时一次；后续单元格中
get_running_loop()总会成功，所以asyncio.run()必然失败 - Flask + eventlet/gevent 场景下，
get_running_loop()可能抛RuntimeError（因未启用 asyncio 兼容模式），需确认运行时环境是否真正支持 asyncio
实际项目里最容易被忽略的，是把 asyncio.run() 当成“万能协程执行器”塞进任何地方——它只适合脚本入口，不适合模块内部或框架回调。一旦进入异步上下文，就得切换思维：协程不是“运行”，而是“调度”。
