Task.WhenAll 仅等待已并发启动的任务，不自动提升效率；需确保任务真正异步发起、合理处理异常、复用 HttpClient 实例并配置超时。
Task.WhenAll 能正确等待所有并发任务完成，但直接用它不等于自动提升接口调用效率——关键在任务是否真正并发发起、异常如何处理、以及结果聚合方式。
Task.WhenAll 本身不发起请求，只是等待已启动的任务
常见误区是把 Task.WhenAll 当作“并发执行器”，其实它只接收 IEnumerable<task></task> 并返回一个 Task。如果任务还没 Start 或是同步阻塞式调用（比如忘了 await），那它们仍是串行的。
- ✅ 正确做法：先用
async方法创建并立即返回 Task（不 await），再统一传给Task.WhenAll - ❌ 错误写法：
var t1 = await httpClient.GetAsync(...)—— 这一步就阻塞了，后续任务根本没机会并发 - 示例片段：
var tasks = new[] { httpClient.GetAsync("https://api1.com/data"), httpClient.GetAsync("https://api2.com/data"), httpClient.GetAsync("https://api3.com/data") }; var results = await Task.WhenAll(tasks); // 所有请求此时已在飞行中
未处理异常会导致整个 WhenAll 失败，且只抛出第一个异常
Task.WhenAll 遇到任意子任务失败（IsFaulted == true），会将整个 Task 置为 Faulted，并仅包装第一个异常（AggregateException.InnerExceptions[0]）。这容易掩盖其他接口的真实错误。
- 推荐策略：用
Task.WhenAll(tasks.Select(t => t.AsTask()))不够；应提前捕获每个任务异常，例如用Task.WhenAll(tasks.Select(t => t.ContinueWith(...)))，或更清晰地用await+ try/catch 包裹每个请求 - 简单健壮方案：用
Task.WhenAll(tasks.Select(async t => { try { return await t; } catch (Exception e) { return null; } }))，再对结果做空值判断 - 注意：返回
null只适合可容忍部分失败的场景；若需区分成功/失败项，建议用元组或自定义结果类型
HttpClient 实例复用不当会引发连接耗尽或 DNS 缓存问题
高频并发调用多个接口时，若每次新建 HttpClient，会快速耗尽端口（TIME_WAIT）、触发 DNS 缓存失效，甚至导致 SocketException。
- ✅ 必须使用单例或静态
HttpClient实例（推荐IHttpClientFactory注入） - ❌ 不要这样写：
using var client = new HttpClient();在循环或高并发方法里 - 配置建议（尤其 .NET Core 5+）：
services.AddHttpClient("myapi", c => { c.Timeout = TimeSpan.FromSeconds(10); }).SetHandlerLifetime(TimeSpan.FromMinutes(5)); - 超时设置要合理：单个请求设 10s，
Task.WhenAll整体不会超过这个时间，但任一任务超时都会让对应 Task 进入 Faulted 状态
真正卡住效率的往往不是 Task.WhenAll 本身，而是 HttpClient 生命周期管理、DNS 解析延迟、服务端限流响应，以及没意识到某些“并发”其实是被线程池或连接数限制住的伪并发。
