c# Task.WhenAll 和 Task.WaitAll 的区别和用法

Task.WaitAll 在 UI 线程中会卡死，因其同步阻塞当前线程，导致界面无响应或死锁；而 Task.WhenAll 是异步非阻塞，需 await 才能安全获取结果或异常，适用于 UI 和 Web 场景。

Task.WaitAll 为什么在 UI 线程里一用就卡死？

因为 Task.WaitAll 是同步阻塞方法：它会**死等所有任务结束，期间当前线程完全停摆**。在 WinForms、WPF 或 ASP.NET Core 的请求线程中调用，等于主动交出控制权又不释放线程，极易引发死锁或界面无响应。

• 只适合控制台程序、后台服务线程，或你100%确定当前线程不是调度关键线程（比如 ThreadPool 工作线程）
• 一旦任一任务抛异常，Task.WaitAll 仍会等全部完成，再把所有异常打包进 AggregateException 抛出
• 没有返回值，无法直接拿到异步任务的计算结果（比如 Task 的返回值）

Task t1 = Task.Run(() => 1);
Task t2 = Task.Run(() => 2
);
Task.WaitAll(t1, t2); // ✅ 可行（控制台）
// ❌ 但 t1.Result 和 t2.Result 不能直接取——它们可能还没完成，或已异常

Task.WhenAll 怎么用才不丢异常、不漏结果？

Task.WhenAll 返回一个 Task（或 Task），必须 await 它才能安全获取结果或捕获异常。它不会阻塞线程，但“失败即停止”：只要有一个输入任务出错，返回的 Task 就立刻进入 Faulted 状态，其余任务**仍在后台运行**（除非你显式取消）。

• 有返回值的任务传入时，await Task.WhenAll(t1, t2) 直接得到 int[] 数组，顺序与参数一致
• 异常不会被吞掉：await 时会直接抛出第一个触发的异常（非 AggregateException），如需收集全部异常，得检查每个 Task 的 Exception 属性
• 若只是想“发出去就不管”，不 await 也没问题——但那就失去了“等待全部完成”的语义

Task t1 = Task.Run(() => { throw new InvalidOperationException("Boom"); });
Task t2 = Task.Run(() => 42);

try
{
    int[] results = await Task.WhenAll(t1, t2); // ⚠️ 这里抛出 InvalidOperationException，t2 实际已成功但结果丢失
}
catch (InvalidOperationException ex)
{
    Console.WriteLine(ex.Message); // "Boom"
}

什么时候该选 WaitAll，什么时候必须用 WhenAll？

不是“哪个更好”，而是“谁敢动谁”。核心判断依据是：你的线程能不能被堵住。

• 必须用 Task.WhenAll：ASP.NET Core 控制器、Blazor 组件、WPF 命令执行、任何带 async 方法签名的上下文
• 可以考虑 Task.WaitAll：命令行工具主函数（static void Main）、后台 Windows Service 的工作线程、单元测试中明确控制生命周期的场景
• 绝对别混用：比如在 async 方法里写 Task.WaitAll(...).Wait() —— 这是双倍阻塞，还可能触发 .NET 的同步上下文死锁机制

常见误操作：以为 WhenAll 是“并行启动 + 等待”，其实它不控制执行时机

Task.WhenAll 本身不启动任务。它只是“观察”一组已经处于运行中（或已创建未启动）的 Task 对象。如果你传的是未 Start() 的 Task（比如用 new Task(...) 构造），它会永远等下去。

• 正确做法：所有任务必须已启动（Task.Run、Task.Factory.StartNew、或手动调用 .Start()）
• 错误示范：var t = new Task(() => DoWork()); Task.WhenAll(t) → t 永远不会完成
• 更隐蔽的坑：传入已 await 过的 Task（比如 await SomeAsync(); var t = SomeAsync();），此时 t 是已完成状态，WhenAll 立刻返回，但逻辑可能不符合预期

真正难的不是语法，而是时刻问自己一句：这个等待，是在释放线程，还是在把它焊死。