asyncio.gather()保持结果顺序且默认失败即停，适合全成功场景；asyncio.wait()返回完成/未完成任务集，适合监听状态变化或竞速响应。
asyncio.gather() 和 asyncio.wait() 的核心区别
用 asyncio.gather() 还是 asyncio.wait()，取决于你是否需要结果顺序、是否容忍单个任务失败、以及是否要提前响应完成事件。
asyncio.gather() 默认保持输入协程的执行顺序，并按原序返回结果；任一任务抛出异常会立即中断全部（除非传 return_exceptions=True）。适合“全成功才继续”的聚合场景。
asyncio.wait() 不保证返回顺序，只返回已完成和未完成的 Task 集合；它更适合监听状态变化，比如“只要有一个完成就处理”，或需区分 done 与 pending 后分别调度。
- 需要结果和调用顺序严格对应 → 选
gather() - 要实现超时后取消剩余任务 →
wait(..., timeout=5)更直接 - 想对第一个完成的任务做响应（如竞速请求）→
wait(..., return_when=asyncio.FIRST_COMPLETED) -
gather()内部其实也基于wait()实现，但封装了结果整理逻辑
控制并发数量：避免 asyncio.create_task() 无节制启动
直接对几百个 URL 调用 asyncio.create_task() 并发发起 HTTP 请求，大概率触发连接池耗尽、服务端限流或本地文件描述符不足（OSError: [Errno 24] Too many open files）。
立即学习“Python免费学习笔记（深入）”；
正确做法是用信号量（asyncio.Semaphore）或任务队列限流：
sem = asyncio.Semaphore(10) # 最多 10 个并发async def fetch(url): async with sem: # 进入前等待，超出则阻塞 return await aiohttp.ClientSession().get(url)
- 别把
Semaphore放在循环外却忘了async with—— 它不是装饰器，不自动生效 - 若用
asyncio.to_thread()包裹 CPU 密集型操作，同样需要限流，否则线程数爆炸 - 某些库（如
aiohttp）自带连接池限制（connector=TCPConnector(limit=100)），但这是传输层限制，和业务逻辑层的语义并发控制不等价
强制顺序执行：什么时候不该用 async/await
如果一组操作天然存在强依赖（例如：先登录 → 拿到 token → 用 token 请求数据 → 用数据提交表单），强行拆成并发任务只会引入竞态、重复登录或 token 过期错误。
此时应放弃“看起来快”，老老实实写成串行 await 链：
token = await login() data = await fetch_with_token(token) result = await submit(data)
- 不要为了“统一用 async”而把同步函数包装成
await asyncio.to_thread(...)再塞进并发池——这反而增加调度开销 - 数据库事务、文件写入、状态机推进等场景，顺序性是正确性的前提，不是性能瓶颈的来源
- 可以用
asyncio.Lock()保护共享状态，但锁本身会削弱并发收益；真需要顺序，不如不并发
asyncio.run() 的隐藏约束与嵌套陷阱
asyncio.run() 只能被最外层调用一次，且会创建并关闭全新的事件循环。在已有运行中的 loop 里再调用它，会报 RuntimeError: asyncio.run() cannot be called from a running event loop。
常见于：Jupyter notebook、FastAPI 路由、或已用 loop.run_until_complete() 启动的脚本中二次调用 run()。
- 在非主模块或框架内，改用
asyncio.create_task()或显式获取当前 loop：asyncio.get_running_loop().create_task(...) - Jupyter 中推荐用
await直接执行协程，而不是包一层asyncio.run() - 测试异步函数时，用
pytest-asyncio插件比手动run()更可靠，它能管理 loop 生命周期
并发控制的难点不在语法，而在识别哪些依赖不可打破、哪些资源有隐式上限、以及何时该主动放弃“并发幻觉”。这些判断没法靠工具自动完成。
