asyncio.gather适合多个独立、无依赖、可并行发起的协程任务，如并发HTTP请求；需传入已调用的协程对象，避免同步阻塞，推荐加return_exceptions=True捕获异常，并用Semaphore控制并发量。
asyncio.gather 适合什么场景
它适合「多个独立、无依赖、可并行发起」的协程任务，比如同时发 5 个 HTTP 请求、读取 3 个文件、调用多个微服务接口。asyncio.gather 会并发启动所有任务，并等待全部完成，返回结果列表（顺序与传入一致）。它不是调度器，不控制执行时机或优先级，也不重试、不超时——这些得自己加。
常见错误现象：RuntimeWarning: coroutine 'fetch_data' was never awaited，本质是把协程对象直接传进 gather 而没调用；或者误以为 gather 能自动处理同步阻塞函数（比如 time.sleep），结果整个事件循环被卡住。
- 必须传入已调用的协程对象（即
fetch(url)，不是fetch） - 不能混入同步阻塞操作；要用
asyncio.to_thread或loop.run_in_executor包装 - 若某任务抛异常，默认全盘失败；加
return_exceptions=True可让异常作为结果项返回
asyncio.create_task 和 asyncio.ensure_future 的区别
asyncio.create_task 是推荐方式，明确表示“现在就调度这个协程”，返回 Task 对象，可随时 cancel() 或检查状态；asyncio.ensure_future 更底层，能接受协程、Future、甚至 Task，但语义模糊，容易误用（比如传入普通函数不报错但无效）。
使用场景：需要提前启动任务、做条件取消、或在循环中动态增减任务时，用 create_task；仅在兼容旧代码或封装通用工具函数时才考虑 ensure_future。
立即学习“Python免费学习笔记（深入）”；
-
create_task必须在事件循环运行中调用，否则报RuntimeError: no running event loop -
ensure_future对非协程输入（如None）可能静默失败，调试困难 - 两者都不等同于
await；任务创建后仍需 await 才能获取结果
如何避免 asyncio.gather 吃掉关键异常
asyncio.gather 默认“一炸全崩”：只要一个协程 raise 异常，整个 gather 就中断，其余任务被取消。这在调试时极难定位哪一环出问题，尤其当任务数多、日志少时。
正确做法是始终加 return_exceptions=True，让异常也作为结果项返回，再逐个检查：
results = await asyncio.gather(
fetch("https://a.com"),
fetch("https://b.com"),
return_exceptions=True
)
for i, r in enumerate(results):
if isinstance(r, Exception):
print(f"Task {i} failed: {r}")
else:
print(f"Task {i} succeeded: {len(r)} bytes")
- 不加
return_exceptions=True时，无法区分是网络超时、JSON 解析失败，还是某个任务根本没启动 - 即使加了该参数，也要注意异常类型：
TimeoutError和ClientConnectorError处理策略不同 - 别在
gather外层套try/except期望捕获所有错误——它只捕获第一个异常，其余已被丢弃
并发量太大导致连接池耗尽或服务拒绝
asyncio.gather 不限并发数，100 个请求会同时发出，极易触发目标服务限流（HTTP 429）、本地端口耗尽（OSError: [Errno 24] Too many open files），或 DNS 查询阻塞。
解决不是靠“换库”，而是加一层可控并发：用 asyncio.Semaphore 限制同时进行的任务数，或改用 asyncio.as_completed 配合队列做流式处理。
- 典型阈值：HTTP 客户端默认连接池一般为 10–100，建议并发控制在 10 以内起步
-
Semaphore必须在协程内acquire()/release()，不能跨await忘记释放 - 别用
time.sleep模拟节流——它会阻塞整个事件循环；改用await asyncio.sleep
print 或写文件）写在协程里没做异步适配。这些不会报错，但会让并发效果归零。 
