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立刻返回，但逻辑可能不符合预期
真正难的不是语法，而是时刻问自己一句：这个等待，是在释放线程，还是在把它焊死。