asyncio.as_completed 为什么返回顺序不固定
它按任务完成时间返回结果，不是按你提交的顺序。比如 task_list = [fetch_a(), fetch_b(), fetch_c()]
如果 fetch_b() 最快返回，as_completed() 就先 yield 它的结果，哪怕它排在第二个。
常见错误现象：以为循环里取到的 result 和原始任务列表索引一一对应，结果数据错位、字段混搭。
用 as_completed() 时，别依赖迭代顺序匹配输入顺序如果必须保持顺序，改用 await asyncio.gather(*tasks)，它保证返回值顺序和参数顺序一致若既要顺序又要实时响应（比如 UI 进度条），得自己给每个 task 包一层带 id 的 wrapper，例如 (i, await coro)
怎么从 as_completed 获取原始任务标识
直接遍历 as_completed() 只拿到 Task 对象或协程结果，没附带上下文。容易踩的坑是：结果来了，但不知道它对应哪个 URL、哪个用户 ID 或哪个重试次数。
立即学习“Python免费学习笔记（深入）”；
推荐做法是把标识信息塞进协程内部，而不是靠外部索引对齐：
用 asyncio.create_task(coro_func(arg, task_id="user_123"))，让业务逻辑自己携带标记或者用 functools.partial 绑定参数：partial(fetch_url, url="https://a.com", tag="a")避免写 for i, t in enumerate(tasks): … tasks[i] 这类“凭空猜身份”的逻辑，异步环境下极易出错
示例片段：
tasks = [ asyncio.create_task(fetch("https://a.com", tag="a")), asyncio.create_task(fetch("https://b.com", tag="b"))]for coro in asyncio.as_completed(tasks): result = await coro # result 已含 tag 字段，无需查表或索引
as_completed 在异常场景下怎么处理
只要有一个任务抛出未捕获异常，as_completed() 不会中断，但你在 await coro 时会直接 raise 那个异常 —— 而且是第一个爆出来的那个，其余还在跑的任务不会自动取消。
这导致两个问题：一是异常掩盖了其他任务状态；二是资源可能泄漏（比如连接没关、文件没 close）。
务必在 await coro 外包 try/except，否则整个循环会提前退出想让一个失败就终止全部？得手动调用 task.cancel() 并 await asyncio.gather(*tasks, return_exceptions=True)更稳妥的做法是：所有任务都用 return_exceptions=True 启动，再统一检查 isinstance(res, Exception)
as_completed 和 gather 性能差异到底在哪
两者底层都用同样的 event loop 调度，性能差别微乎其微。真正影响速度的是你怎么做后续处理。
as_completed() 的开销在于每次 yield 都要唤醒一次事件循环；gather() 是等全部结束才返回。所以：
如果你需要“一有结果就立刻处理（如写日志、发通知、更新缓存）”，as_completed() 更合适如果只是等全做完再批量入库或校验，gather() 代码更直白，也更容易做超时控制（timeout= 参数直接生效）注意：as_completed() 本身不接受 timeout，得靠 asyncio.wait_for(coro, timeout=) 包每项任务
复杂点在于：一旦任务间有依赖或需动态启停（比如前一个结果决定要不要启动下一个），as_completed() 的流式特性就不可替代 —— 但这部分逻辑得你自己组织，库不帮你做。
评论(0)