事件循环是单线程协程调度器，依赖await主动让出控制权，不处理CPU密集任务，推荐用asyncio.run()启动。
事件循环本质是单线程调度器，不是多线程或多进程
asyncio 事件循环不是并发执行的“引擎”，而是一个在单线程内轮询、挂起、恢复协程的调度器。它不创建新线程，也不抢占式切换——所有协程必须主动 await 才能让出控制权。这意味着：如果你写了一个 CPU 密集型的 while True: 循环却没 await，整个事件循环就卡死，其他协程永远得不到执行机会。
- 它只在
await表达式处做上下文切换（比如await asyncio.sleep(1)、await response.json()） - 底层依赖操作系统提供的非阻塞 I/O 机制（如 Linux 的 epoll、macOS 的 kqueue），但 Python 层完全屏蔽了这些细节
- 一个 Python 进程默认最多只有一个运行中的事件循环（
asyncio.get_running_loop()报RuntimeError就说明当前没在 loop 里）
asyncio.run() 是最安全的启动方式，别手动管理 loop
Python 3.7+ 强烈建议用 asyncio.run(main()) 启动，它会自动创建新 loop、运行协程、正确关闭资源。手动调用 asyncio.new_event_loop() + loop.run_until_complete() 容易出错：
- 在已存在 loop 的环境中（如 Jupyter、某些 Web 框架）重复创建会报
RuntimeError: there is already a current event loop - 忘记调用
loop.close()可能导致资源泄漏（尤其在反复测试时） -
asyncio.get_event_loop()已被弃用（自 3.10 起 warn），它可能返回过期或未启动的 loop
示例对比：
# ✅ 推荐：简洁、健壮、自动清理
async def main():
await asyncio.sleep(1)
print("done")
asyncio.run(main())
❌ 风险高：需自行处理异常、关闭、嵌套限制
loop = asyncio.new_event_loop()
try:
loop.run_until_complete(main())
finally:
loop.close() # 忘记这行？下次 run() 可能失败
协程挂起 ≠ 线程阻塞，但 await 对象必须是“可等待的”
当你写 await func()，Python 要求 func() 返回的是协程对象（coroutine）、Task、Future 或实现了 __await__ 的对象。否则会报 TypeError: object XXX can't be used in 'await' expression。
立即学习“Python免费学习笔记（深入）”；
- 常见错误：直接
await time.sleep(1)→ 错！time.sleep是同步阻塞函数，必须换成await asyncio.sleep(1) - 调用普通函数（哪怕里面含异步逻辑）不会自动变成协程：要确保函数本身用
async def定义，并且调用它返回的是协程对象（即没加()就只是函数，加了才是可 await 的协程） - 第三方库若未适配 asyncio（如 requests），不能直接
await requests.get(...)；得换aiohttp或用asyncio.to_thread()（3.9+）包装
事件循环不处理 CPU 密集型任务，那是它的盲区
asyncio 的优势只在 I/O 密集场景（HTTP 请求、数据库查询、文件读写）。一旦遇到纯计算（如解析大 JSON、图像缩放、加密解密），事件循环无法“切走”，整个线程就被占住——此时并发优势归零，甚至比同步还慢（因多了协程调度开销）。
- 解决方案只有两个：
asyncio.to_thread()（推荐，3.9+）把 CPU 工作扔进线程池；或用concurrent.futures.ProcessPoolExecutor进程池（适合真正重计算） - 别试图用
await asyncio.sleep(0)“让出控制权”来缓解 CPU 占用——它无效，因为没触发真正的挂起点 - 监控手段：用
asyncio.current_task().get_coro()查看当前正在跑什么，配合sys.settrace或trio类工具可定位卡点
事件循环的精妙之处不在“快”，而在“省”——省线程、省内存、省上下文切换开销。但它对“该让谁先跑”的判断，完全取决于你是否写了正确的 await 点。漏掉一个，整条流水线就堵死。
