Task.WaitAll 为什么在 UI 线程里一用就卡死？
因为
Task.WaitAll是同步阻塞方法：它会**死等所有任务结束，期间当前线程完全停摆**。在 WinForms、WPF 或 ASP.NET Core 的请求线程中调用，等于主动交出控制权又不释放线程，极易引发死锁或界面无响应。 只适合控制台程序、后台服务线程，或你100%确定当前线程不是调度关键线程（比如
ThreadPool工作线程） 一旦任一任务抛异常，
Task.WaitAll仍会等全部完成，再把所有异常打包进
AggregateException抛出 没有返回值，无法直接拿到异步任务的计算结果（比如
Task<int></int>的返回值）
Task<int> t1 = Task.Run(() => 1); Task<int> t2 = Task.Run(() => 2); Task.WaitAll(t1, t2); // ✅ 可行（控制台） // ❌ 但 t1.Result 和 t2.Result 不能直接取——它们可能还没完成，或已异常
Task.WhenAll 怎么用才不丢异常、不漏结果？
Task.WhenAll返回一个
Task（或
Task<t></t>），必须
await它才能安全获取结果或捕获异常。它不会阻塞线程，但“失败即停止”：只要有一个输入任务出错，返回的
Task就立刻进入 Faulted 状态，其余任务**仍在后台运行**（除非你显式取消）。 有返回值的任务传入时，
await Task.WhenAll(t1, t2)直接得到
int[]数组，顺序与参数一致 异常不会被吞掉：
await时会直接抛出第一个触发的异常（非
AggregateException），如需收集全部异常，得检查每个
Task的
Exception属性 若只是想“发出去就不管”，不 await 也没问题——但那就失去了“等待全部完成”的语义
Task<int> t1 = Task.Run(() => { throw new InvalidOperationException("Boom"); });
Task<int> 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立刻返回，但逻辑可能不符合预期 真正难的不是语法，而是时刻问自己一句：这个等待，是在释放线程，还是在把它焊死。
