Python 3.10+ 中 asyncio.get_event_loop() 不再自动创建事件循环，仅检查当前线程是否有已设置或运行中的循环，否则直接抛 RuntimeError；应优先使用 get_running_loop()（协程内）或 asyncio.run()（主线程顶层），多线程中须用 run_coroutine_threadsafe 或显式新建并绑定 loop。
asyncio.get_event_loop() 在 Python 3.10+ 不再自动创建事件循环，只查当前线程是否已有运行中或已设置的循环；没找到就直接抛 RuntimeError，不是 bug，是设计变更。
为什么调用 get_event_loop() 突然报 "There is no current event loop"
Python 3.10 彻底移除了「兜底创建」逻辑。它现在只做两件事：
– 检查当前线程是否已通过 asyncio.set_event_loop() 设置过循环
– 或者是否已有循环正在运行（比如 asyncio.run() 启动后）
两者都不满足，就立刻抛 RuntimeError: There is no current event loop in thread 'xxx'，不警告、不 fallback。
常见触发点包括：
- 在普通同步函数里写
if __name__ == "__main__": loop = asyncio.get_event_loop() - 在 Celery 任务、
ThreadPoolExecutor子线程、FastAPI 后台任务中直接调用 - macOS 12+ 上因 kqueue 兼容性问题，主线程也可能拿不到默认循环
get_running_loop() 和 get_event_loop() 到底该用谁
asyncio.get_running_loop() 是协程内部唯一推荐的接口——它只认“此刻正在跑的循环”，轻量且安全；asyncio.get_event_loop() 已被官方文档标记为 deprecated，3.13+ 中连回退逻辑都删干净了。
关键区别：
-
get_running_loop()：必须在async def函数内、且事件循环已启动后才能调，否则立刻报错 -
get_event_loop()：3.10+ 中纯属“取一个可能不存在的东西”，行为不可靠 - 两者都不该出现在模块顶层、
__init__、或任何同步函数里
asyncio.run() 为什么不是万能解药
asyncio.run() 确实能绕过手动管理循环的麻烦，但它有硬边界：
- 只能在主线程顶层调用一次，二次调用会报
RuntimeError: asyncio.run() cannot be called from a running event loop - 不能嵌套在已运行的 loop 中（如 Jupyter、Tornado、aiohttp server 内部）
- 无法跨线程复用——子线程里调
asyncio.run()会新建 loop，但该 loop 与主线程隔离，无法通信或共享状态
所以你在 Celery 任务、后台线程、GUI 子线程里看到 There is no current event loop，不是 asyncio.run() 失效了，而是它根本没机会介入。
多线程中调度协程的正确姿势
从非主线程（比如 threading.Thread）里触发协程，不能直接 await 或调 loop.create_task()，因为 loop 不在当前线程。
错误做法：
- 在子线程里调
asyncio.get_event_loop()→ 报No current event loop - 拿到主线程的 loop 后直接
loop.create_task()→ 报Non-thread-safe operation invoked on an event loop other than the current one
正确做法只有两个：
- 用
asyncio.run_coroutine_threadsafe(coro, main_loop)，把协程提交给主线程 loop 执行（推荐） - 在子线程里显式创建新 loop：
loop = asyncio.new_event_loop()+asyncio.set_event_loop(loop)+loop.run_until_complete(coro)（注意 loop 与线程强绑定）
最容易被忽略的是：loop 的生命周期和线程绑定是硬约束，不是可协商的兼容层——一旦跨线程误用，错误信息往往不指向根源，而是表现为随机挂起或静默失败。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
