最可靠方式是调用 asyncio.get_running_loop()，它仅在当前线程有正在运行的事件循环时返回 loop，否则抛出 RuntimeError；不可用 get_event_loop() 或盲目捕获异常后启动新 loop。
如何判断是否已有正在运行的 asyncio 事件循环
直接调用 asyncio.get_running_loop() 是最可靠的方式。它只在事件循环正在运行且当前线程中存在时才返回 loop 对象；否则抛出 RuntimeError: no running event loop。不要用 asyncio.get_event_loop()，它可能返回未启动的 loop 或在策略变更后行为不一致。
常见错误是捕获异常后盲目创建新 loop（比如在主线程中调用 loop.run_until_complete() 前未检查），这会导致嵌套 loop 或 RuntimeError。
- 仅在想“立刻执行异步逻辑”前做此检测，比如封装一个既支持 sync 又支持 async 的工具函数
- 在子线程中调用时，
get_running_loop()总是失败（每个线程最多一个 running loop，且需手动 set） - Python 3.7+ 才有
get_running_loop()；3.6 及更早需用asyncio._get_running_loop()（私有 API，不推荐）
为什么不能只靠 try/except 来“自动启动 loop”
很多示例代码看到 RuntimeError 就直接 asyncio.run() 或 loop.run_until_complete()，这在交互式环境或顶层脚本里看似可行，但会破坏调用上下文：
- 如果当前已在某个 loop 中（如 Jupyter、FastAPI、aiohttp server），再调用
asyncio.run()会报RuntimeError: asyncio.run() cannot be called from a running event loop -
asyncio.run()总是新建并关闭 loop，无法复用现有资源（如已连接的 TCP 连接池、缓存的 DNS 解析结果） - 在多线程场景下，误启 loop 可能导致
RuntimeError: There is no current event loop in thread 'xxx'
安全封装同步/异步共用函数的写法
典型场景：一个 fetch_data() 函数，用户可能在普通函数里调用，也可能在 async def 里 await。这时需按运行环境自动适配：
import asyncio
<p>def fetch_data(url):
try:
loop = asyncio.get_running_loop()
except RuntimeError:</p><h1>没有 running loop → 同步调用</h1><pre class="brush:php;toolbar:false;"> return asyncio.run(_fetch_coro(url))
else:
# 有 running loop → 返回 coroutine，由调用方 await
return _fetch_coro(url)async def _fetch_coro(url):
实际异步逻辑
return await asyncio.sleep(0.1, result=f"done for {url}")
注意：asyncio.run() 内部会调用 loop.close()，所以不能在长期运行的服务中反复用它驱动协程。
在测试或调试时快速确认 loop 状态
最简验证方式是在 Python REPL 或脚本开头加一行：
import asyncio print(asyncio.get_running_loop() if hasattr(asyncio, 'get_running_loop') else 'no running loop')
或者捕获异常：
try:
asyncio.get_running_loop()
print("✅ running")
except RuntimeError:
print("❌ not running")
别依赖 asyncio.get_event_loop().is_running() —— 它返回 False 即使 loop 已创建但尚未 start，而 get_running_loop() 才真正反映“此刻能否 await 协程”。
真正容易被忽略的是：loop 是否 running 和 loop 是否存在是两回事；asyncio 的很多陷阱都源于混淆了“已创建”“已启动”“正在运行”这三个状态。
