asyncio.get_event_loop() 在 Python 3.10+ 被弃用，因它不再自动创建事件循环，仅返回已设置的循环；未设则触发 DeprecationWarning（3.10–3.12）或 RuntimeError（3.13+），推荐改用 asyncio.run() 或显式 new_event_loop()。
asyncio.get_event_loop() 在 Python 3.10 中触发弃用警告，不是策略本身有问题，而是它隐式依赖「自动创建默认事件循环」的行为被明确否定——你不能再指望它兜底了。
为什么 get_event_loop() 会报 DeprecationWarning？
Python 3.10 开始收紧逻辑：get_event_loop() 不再尝试创建新循环，只返回「已设置」的当前循环。如果线程里没手动 set 过、也没跑过 asyncio.run()，它就直接抛 RuntimeError 或先发 DeprecationWarning（3.10–3.12），3.13+ 已完全移除回退路径。
常见触发场景：
- 在普通函数里直接调用
get_event_loop()，而非协程或回调中 - 在子线程里未调用
set_event_loop()就试图获取 - Jupyter 内核已启动 loop，但你又在模块顶层重复调用
get_event_loop()
get_running_loop() 是什么情况下必须用？
它只在「已有运行中的事件循环」上下文中安全，且仅限协程或回调内调用。一旦你在 async def 函数里需要访问当前 loop（比如注册回调、调用 call_soon_threadsafe），就必须用它，而不是 get_event_loop()。
典型错误：
立即学习“Python免费学习笔记（深入）”；
-
await外部调用get_running_loop()→ 报RuntimeError: no running event loop - 在
threading.Thread的run()方法里调用 → 即使主线程有 loop，子线程也没有 - 误以为它能替代
new_event_loop()→ 它不创建，只获取
自定义事件循环策略（如 uvloop）为什么在 3.10+ 更难生效？
旧写法 asyncio.set_event_loop_policy(uvloop.EventLoopPolicy()) 仍有效，但如果你接着用 get_event_loop()，策略不会自动触发创建——因为该函数已放弃“按需新建”逻辑。策略真正起效，得靠 asyncio.run() 或显式 new_event_loop()。
正确链路：
- 先设策略：
asyncio.set_event_loop_policy(uvloop.EventLoopPolicy()) - 再创建：
loop = asyncio.new_event_loop()（此时用的是 uvloop） - 或启动：
asyncio.run(main())（也走策略，但仅限顶层） - 别再依赖
get_event_loop()来“顺便创建”
为什么 asyncio.run() 不报这个警告，却也逐渐被弃用？
asyncio.run() 内部仍调用 get_event_loop() 做初始化，但它封装了整个生命周期，所以用户不直接暴露。问题在于它强制单次、主线程、全局 loop，和现代服务（多租户、嵌入式、测试隔离）冲突。PEP 705 正是为解决这类隐式耦合——Runner 显式隔离实例，而 get_event_loop() 的弃用，是同一治理逻辑的底层呼应。
真正容易被忽略的点：即使你不用 get_event_loop()，只要第三方库（比如老版本 aiohttp 或 tornado）内部还调它，升级到 3.10+ 后照样触发警告。这不是你的代码错，但你得推动依赖更新，或加临时兼容层。
