asyncio.as_completed按任务完成时间而非提交顺序返回结果，易导致数据错位；需用task标识或gather保持顺序，异常时需手动处理以防资源泄漏。
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 或哪个重试次数。
推荐做法是把标识信息塞进协程内部，而不是靠外部索引对齐：
- 用
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() 的流式特性就不可替代 —— 但这部分逻辑得你自己组织，库不帮你做。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
