asyncio 通过单线程事件循环调度协程实现并发，任务（Task）是调度基本单位，需主动 await 让出控制权；应使用 create_task 并行启动任务，避免直接 await 导致串行阻塞。
理解 asyncio 的核心调度机制
asyncio 不是多线程或多进程，它靠单线程内的事件循环（Event Loop）驱动协程并发执行。任务（Task）是被事件循环调度的基本单位，本质是包装了协程的可等待对象。调度的关键在于：协程主动让出控制权（如 await 一个 awaitable），事件循环才能切换到下一个就绪任务。
常见误区是以为 await 就等于“等待完成”，其实它只是暂停当前协程、交还控制权——如果 await 的对象还没准备好（比如网络未返回、sleep 时间未到），事件循环就会去运行其他可运行的任务。
合理创建与管理 Task，避免隐式阻塞
直接用 await coro() 是同步等待，会阻塞整个协程链；而用 asyncio.create_task(coro()) 才是真正并发启动任务。多个任务应尽早并行创建，再统一 await 它们的完成。
- ✅ 推荐：tasks = [asyncio.create_task(fetch(url)) for url in urls]; await asyncio.gather(*tasks)
- ❌ 避免：for url in urls: await fetch(url) —— 串行执行，失去异步意义
- ⚠️ 注意：create_task 必须在事件循环运行中调用，不能在普通函数或同步上下文里直接用
用 asyncio.gather、asyncio.wait 和 asyncio.as_completed 区分调度意图
三者都用于并发等待多个协程，但语义和行为不同：
立即学习“Python免费学习笔记（深入）”；
- gather：按输入顺序返回结果，任一异常立即抛出（可设 return_exceptions=True）
- wait：返回已完成（done）和待处理（pending）任务集合，适合需要超时控制或条件退出的场景
- as_completed：按实际完成顺序迭代结果，适合“谁先返回谁先处理”的流式逻辑，比如实时日志聚合或竞速请求
性能优化的几个关键实践
异步不等于自动高效，瓶颈常出现在 I/O 策略、协程粒度和资源竞争上：
- 限制并发数：用 asyncio.Semaphore 控制同时发起的请求数，防止压垮服务端或触发限流
- 避免 CPU 密集型操作：asyncio 默认在主线程运行，耗时计算会阻塞事件循环；应通过 loop.run_in_executor 移至线程池/进程池
- 复用连接：HTTP 客户端（如 httpx.AsyncClient 或 aiohttp.ClientSession）要跨请求复用 session，否则每次新建连接开销大
- 慎用 sleep：asyncio.sleep(0) 可主动让出控制权，但频繁调用可能增加调度开销；非必要不插空
调试与可观测性小技巧
asyncio 任务出问题常表现为“卡住”“不执行”或“结果丢失”。几条实用建议：
- 启用调试模式：asyncio.run(main(), debug=True)，会提示未 await 的协程、慢回调等警告
- 查看正在运行的任务：asyncio.all_tasks() + task.get_coro() 帮助定位挂起位置
- 给任务命名：asyncio.create_task(coro(), name="fetch_user_123")，便于日志追踪
- 用 async-timeout 包替代裸 try/except + asyncio.wait_for，更健壮地处理超时
