asyncio.wait 不控制任务执行顺序，仅并发等待可等待对象完成；需顺序执行时应直接 await，有依赖的并发任务应封装为内部串行的协程单元。
asyncio.wait 不能控制任务执行顺序
它只负责并发等待一组可等待对象（awaitable）完成，不干预谁先启动、谁先挂起、谁依赖谁。很多人看到 asyncio.wait 返回 done 和 pending 就误以为能靠它“调度顺序”，结果发现任务输出乱序、甚至 InvalidStateError 报错——根本原因在于：它不负责启动任务，也不保证执行流。
常见错误现象：
- 提前
create_task(a())，又在wait后直接await b()，但b()根本没被调度过 - 用
wait([a(), b(), c()])期望按 a→b→c 执行，实际是三者同时进入就绪队列，谁先await完谁先进done - 把
return_when=asyncio.FIRST_COMPLETED当作“让第一个先跑”，其实它只是等第一个完成，其余早已并发运行
需要顺序执行时，直接 await 就够了
如果 A 必须完成后 B 才能开始（比如 A 返回 token，B 拿 token 请求），最直白、最可靠的方式就是放弃封装，老老实实串行 await：
async def fetch_token():
await asyncio.sleep(1)
return "abc123"
<p>async def fetch_profile(token):
await asyncio.sleep(0.5)
return {"name": "Alice", "token": token}</p><p>async def main():
token = await fetch_token() # A 完成后才往下走
profile = await fetch_profile(token) # B 等 A 结果，天然顺序
return profile
</p>
这种写法没有隐藏状态，不会漏掉 await，也不会因 Task 被 cancel 而中断。只要协程内部有 await，事件循环就会自然穿插调度；没有依赖时再考虑并发。
想并发但又要部分顺序，得把依赖逻辑收进协程里
比如你有 3 个用户要查资料，但每个用户都必须先登录（A）、再查档案（B），且登录和查档之间有数据传递。这时不能把 6 个动作平铺进 wait 或 gather，而应封装成带内部顺序的单元：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 定义
async def user_flow(user_id): token = await login(user_id); return await get_profile(token) - 再用
await asyncio.gather(*[user_flow(u) for u in users])并发跑这些单元 - 单元内是串行，单元间是并发——这才是符合直觉的分层控制
强行拆开 login + get_profile 去用 wait 协调，只会引入 asyncio.Queue 或 asyncio.Event 这类复杂原语，增加出错概率，还掩盖真实依赖。
asyncio.wait 的真实适用场景
它适合做响应式判断，不是流程编排工具。典型用法包括：
- 超时控制：
await asyncio.wait(tasks, timeout=5)，超时后手动处理pending - 竞速获取首个可用结果：
done, _ = await asyncio.wait(tasks, return_when=asyncio.FIRST_COMPLETED)，然后result = done.pop().result() - 容错中止：
return_when=asyncio.FIRST_EXCEPTION，一旦任一任务抛异常就立刻退出
注意：done 是按完成时间排序的，不是按你传入顺序；pending 里是还在跑或已 cancel 的 Task，它们的状态需要你自己检查和清理——这点很容易被忽略，尤其在短生命周期脚本里，未 await 的 pending Task 可能直接被丢弃。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
