Task.WhenAll适用于彼此独立、无依赖且需等待全部完成的场景，如批量HTTP请求；不适用于有依赖或需容错的任务，且需注意异常处理、并发控制和.NET版本差异。
Task.WhenAll 什么时候该用，什么时候不该用
它不是万能的并发开关，只适合「彼此独立、无依赖、最终要等全部完成」的场景。比如同时调用多个微服务接口拉取用户资料，或并行写入多个日志文件。一旦某个 Task 抛异常，Task.WhenAll 返回的 Task 就会直接失败，不会等其他任务结束——这点和 Task.WaitAll 的行为逻辑不同，但很多人误以为它们是“同步/异步版”的对应关系。
- 适合：批量 HTTP 请求、并行 I/O、独立数据预处理
- 不适合：有先后依赖的任务链（该用
await链式调用）、需要逐个容错处理的场景（该用Task.WhenAll+ContinueWith或手动try/catch包裹每个子任务） - 注意：
Task.WhenAll不会改变任务的调度线程，它只是组合；真正决定在哪执行的，是每个子Task自身的实现（比如HttpClient.GetAsync内部调度）
怎么安全地捕获每个子任务的异常
直接 await Task.WhenAll(tasks) 一出错就崩，连哪个子任务挂了都难定位。常见错误是把整个数组丢进去，然后在 catch 里只抓一个 AggregateException，却不拆解里面的 InnerExceptions。
- 推荐做法：先让每个子任务自行包裹
try/catch，返回ValueTuple或封装成Result类型 - 或者用
Task.WhenAll(tasks.Select(t => t.AsTask().ContinueWith(...)))，但要注意ContinueWith默认不继承父上下文，得显式传TaskContinuationOptions.ExecuteSynchronously防止线程切换开销 - 别依赖
task.Exception—— 它只在IsFaulted == true时有效，且可能为null（比如被取消）
性能陷阱：数量大时为什么反而变慢
Task.WhenAll 本身开销极小，但并发数失控会导致资源耗尽。比如对 1000 个 URL 调用 HttpClient.GetAsync，没加限流，很容易触发连接池耗尽、DNS 查询阻塞或远程服务限流，结果整体耗时比串行还长。
- 默认
HttpClient连接池上限是 2（.NET Core 2.x）或 10（.NET 5+），超出会排队等待 - 解决方案不是换库，而是用
SemaphoreSlim控制并发度，例如限制最多 16 个请求同时发出 - 避免在循环里反复创建
HttpClient实例——它本应是单例，否则会引发端口耗尽（SocketException: Address already in use） - 如果任务本质是 CPU 密集型（如大量 JSON 解析），
Task.WhenAll不会提升性能，甚至因线程争抢更慢；此时该用Parallel.ForEachAsync（.NET 6+）或手动分片 +Task.Run
.NET 版本差异导致的行为变化
老项目升级到 .NET 6/7 后，有人发现 Task.WhenAll 等待时间变短了，不是代码改了，是底层调度器变了。.NET 5 开始引入「协作式取消」优化，Task.WhenAll 对已取消任务的响应更快；而 .NET 6+ 的 ValueTask 支持也让某些包装场景（如 EF Core 的 ToListAsync）延迟更低。
- .NET Core 2.1–3.1：
Task.WhenAll对空集合返回已完成任务，但部分早期补丁版本存在竞态，建议升级到 3.1.30+ - .NET 5+：支持
Task.WhenAll直接推导泛型类型，不用显式指定Task[] - 别混用
ValueTask和Task数组传给Task.WhenAll——编译报错：The type 'ValueTask' cannot be used as type argument
并发不是加个 WhenAll 就完事，关键在理解每个子任务的真实成本、失败模式和资源边界。漏掉连接池配置或异常分解，线上出问题时根本看不出哪一环断的。
