Task.WhenAll 不会阻塞主线程，它同步返回组合任务，真正等待发生在 await 时，此时线程被释放；错误用法如 .Wait() 或 .Result 会导致死锁。
Task.WhenAll 会阻塞主线程吗
不会。Task.WhenAll 本身是同步返回一个 Task，不等待任何子任务完成，只是把多个 Task 聚合成一个可 await 的组合任务。真正“等待”发生在你 await 它的时候，此时当前 async 方法挂起，线程（比如 UI 线程或 ASP.NET 请求上下文）被释放，不是阻塞。
常见误解是写成：Task.WhenAll(tasks).Wait() 或 Task.WhenAll(tasks).Result —— 这会在同步上下文中强行阻塞线程，极易引发死锁（尤其在 WinForms、WPF、ASP.NET Core 旧版同步上下文场景中）。
- ✅ 正确：
await Task.WhenAll(tasks) - ❌ 危险：
Task.WhenAll(tasks).Wait()、Task.WhenAll(tasks).Result、Task.Run(() => Task.WhenAll(tasks)).Result
Task.WhenAll 和 Task.WaitAll 的关键区别
Task.WhenAll 是 async/await 友好型，返回 Task（或 Task<TResult[]>），支持异步流；Task.WaitAll 是同步阻塞型，返回 void，必须在线程池线程或无上下文环境里用，否则大概率死锁。
-
Task.WhenAll：适用于async方法内部，能保持上下文流动（如 HttpContext、SynchronizationContext） -
Task.WaitAll：仅适合控制台程序、后台服务线程、或明确剥离了同步上下文的Task.Run内部 - 类型推导差异：
Task.WhenAll(t1, t2)若t1和t2是Task<int>，返回Task<int[]>；Task.WaitAll不返回结果，需手动读取Task.Result
异常聚合行为：为什么有时只看到一个 Exception
Task.WhenAll 在所有子任务完成后才完成，但如果任意一个子任务出错，它会立即进入 Faulted 状态，并把所有异常打包进一个 AggregateException（即使只有一个失败任务，也会包一层）。但注意：如果你用 await，C# 会自动解包，抛出第一个异常（不是全部）；只有直接访问 .Exception 属性时才会看到完整 AggregateException。
- ✅ 捕获全部异常：
try { await Task.WhenAll(tasks); } catch (AggregateException ex) { foreach (var inner in ex.InnerExceptions) { /* 处理每个 */ } } - ⚠️ 默认行为：
await后只抛第一个异常，其余被“吞掉”，容易漏诊断 - 若需区分成功/失败项，建议用
Task.WhenAll(tasks).ContinueWith(...)并检查t.IsFaulted和t.Exception
性能与内存：大量任务时要不要分批
没有硬性数量阈值，但当传入几千个 Task 时，Task.WhenAll 内部会分配数组并注册大量 continuation，可能触发 GC 压力或调度延迟。这不是语法错误，而是工程权衡。
- 一般几百以内安全；超过 1000 个建议按需分批，例如每 100 个一组调用
Task.WhenAll，再对组结果await Task.WhenAll(groups) - 避免传入已
Completed的任务（如Task.FromResult(42)）过多——它们仍参与调度逻辑，无实际并发收益 - 如果任务本身是 I/O 密集型（如 HTTP 请求），瓶颈不在
WhenAll，而在连接池或服务端限流；CPU 密集型任务则更应考虑Task.Run+ 分批 +ConfigureAwait(false)
真正容易被忽略的是异常处理粒度和上下文捕获成本——尤其在 ASP.NET Core 中，默认开启的 Capture 会让每个 continuation 都保存上下文快照，大批量任务下开销明显。必要时可在非 UI/非请求上下文路径显式加 .ConfigureAwait(false)。
