Task.WhenAll本身不控制并发，仅等待所有Task完成；是否并发取决于传入Task的创建方式，如Task.Run会并行，而Task.FromResult则无并发。
Task.WhenAll 什么时候会真正并发执行
它本身不控制并发，只负责“等待多个 Task 全部完成”。真正是否并发，取决于你传进去的那些 Task 是怎么创建的。比如你用 Task.Run(() => DoWork()) 启动 5 个，它们大概率并行；但如果你写的是 new Task 或者更糟——把同步方法直接包成 Task.FromResult(...)，那根本没并发，只是假装异步。
常见错误现象：Task.WhenAll 耗时接近单个任务耗时，而不是最慢那个（说明压根没并发）
- 检查每个子
Task是否真由线程池调度（Task.Run、async/awaitI/O 操作等） - 避免手动构造
Task后调用Start()——容易漏掉异常捕获和调度上下文 - I/O 密集场景优先用原生
async方法（如HttpClient.GetAsync），别用Task.Run包同步调用
Task.WhenAll 返回值类型怎么推导
返回的是 Task，不是 Task，也不是 Task。数组是唯一确定的返回类型，这点在泛型推导和 await 后变量声明时特别关键。>
使用场景：你 await Task.WhenAll(t1, t2, t3)，结果直接是 int[]（如果三个都是 Task），不是 IEnumerable，不能直接 foreach（得先 await 完）
- 如果传入空集合（如
Task.WhenAll(new Task[0])），返回Task，不是Task，注意泛型擦除陷阱 - 混合类型（
Task和Task）无法直接传给Task.WhenAll—— 编译不过，得统一转成Task或用Task.WhenAll((IReadOnlyList)list) - VS 提示“无法推断类型”？显式指定泛型参数：
await Task.WhenAll(t1, t2, t3)
异常处理：一个失败，全部“失败”吗
是的，只要任意一个子 Task 进入 Faulted 状态，Task.WhenAll 返回的 Task 就会变成 Faulted，且 Exception.InnerExceptions 包含所有失败项的异常 —— 但注意，**不是所有**，而是“第一个被观察到的”或“聚合后打包的”，具体取决于 .NET 版本和调度时机。
容易踩的坑：用 try/catch 捕获 Task.WhenAll 的异常后，以为能拿到全部错误，结果 e.InnerException 只有部分；或者没展开 AggregateException，直接打印 e.Message，看到的是“One or more errors occurred.”这种无意义提示
- 务必用
catch (AggregateException ex)，然后遍历ex.InnerExceptions - 如果想让某个失败不影响整体（即“尽力而为”），改用
Task.WhenAll(tasks.Select(t => t.ContinueWith(...)))，或自己封装 fallback 逻辑 - .NET 6+ 中
Task.WaitAll已标记为 obsolete，别混用同步等待方式来绕过异常聚合
性能影响：开销在哪，什么情况下不该用
主要开销不在“等待”，而在异常聚合、状态机编排和内存分配（返回数组、包装 AggregateException）。对几十个以内轻量级 Task，影响可忽略；但若你传入上千个 Task，尤其每个都短命且带异常可能，Task.WhenAll 会成为瓶颈。
典型误用场景：循环里反复调用 Task.WhenAll 处理小批量请求（比如每 5 个一批），不如合并成大批次或改用 Channel + 限流
- 避免在热路径中对大量
Task（>100）调用Task.WhenAll—— 改用Task.WhenAny配合队列，或引入并发限制（如SemaphoreSlim） - 调试时发现
Task.WhenAll占用高 CPU？大概率是子Task本身卡在同步阻塞（如Thread.Sleep、Task.Result），不是WhenAll的锅 - 底层原理上，它不新建线程，也不干预调度器 —— 所有子
Task仍按各自方式运行，WhenAll只是一个观察者 + 聚合器
最常被忽略的一点：Task.WhenAll 不保证子 Task 的完成顺序，返回数组索引对应传入顺序，但执行先后完全不可控 —— 别把它当“有序并发”用。
