task.whenall不会短路，所有任务均运行到底；它并发等待全部完成，异常时抛aggregateexception（.net6+单异常扁平化），需用cancellationtoken显式取消才能实现短路。
Task.WhenAll 不会短路，所有任务都会运行到底
很多人误以为 Task.WhenAll 像逻辑运算符（如 &&）那样“短路”——一旦某个任务出错就立刻停止其余任务执行。事实相反：Task.WhenAll **从不取消或中断**已启动的任务，它只是等待所有任务完成（无论成功或失败），然后统一返回结果或抛出异常。
这意味着：即使第一个 Task 立即抛出 InvalidOperationException，后面那些耗时 10 秒的 Task.Delay(10000) 依然会继续跑完。
- 行为本质是“并发等待”，不是“条件控制”
- 没有内置取消传播；若需提前终止，请显式使用
CancellationToken - 常见误用场景：用
WhenAll替代“只要一个成功就停”的逻辑（此时应考虑Task.WhenAny+ 手动取消）
异常会被打包进 AggregateException，但细节容易丢失
Task.WhenAll 在至少一个任务出错时，会抛出 AggregateException，其 InnerExceptions 包含所有失败任务的异常。但有三个关键细节常被忽略：
- 如果只有一个任务失败，.NET 6+ 默认会“扁平化”抛出那个原始异常（而非包裹在
AggregateException中），这是为了简化调试 —— 但行为取决于目标框架版本和是否启用了ThrowUnobservedTaskExceptions - 多个异常时一定走
AggregateException，但你不能假设e.InnerException就是第一个失败任务的异常（顺序不保证） - 若任务因取消而失败（
TaskCanceledException），它也会进入InnerExceptions，需用e.IsCancellationRequested或检查e.GetType() == typeof(TaskCanceledException)区分
var tasks = new[] {
Task.Run(() => { throw new InvalidOperationException("A"); }),
Task.Run(() => { throw new ArgumentException("B"); })
};
try {
await Task.WhenAll(tasks);
} catch (AggregateException ae) {
foreach (var ex in ae.InnerExceptions) {
Console.WriteLine($"{ex.GetType().Name}: {ex.Message}");
}
}想实现真正的“短路”？得自己加 CancellationToken
要让其他任务在首个失败时立即停止，必须配合 CancellationTokenSource 主动取消。注意：这要求所有参与的 Task 都支持取消（即接受 CancellationToken 并响应）。
- 不要只在
WhenAll外层 try/catch 后调用cancellationTokenSource.Cancel()—— 此时任务可能已结束或正在收尾，取消无效 - 推荐模式：创建
CancellationTokenSource，把 token 传给每个子任务，并在任意任务出错时立刻Cancel() - 未响应取消的代码（如死循环、同步 IO）仍会继续执行，
CancellationToken不是强制杀进程的指令
var cts = new CancellationTokenSource();
var tasks = new[] {
Task.Run(() => { /* 检查 cts.Token.IsCancellationRequested */ }, cts.Token),
Task.Run(() => { throw new Exception("Boom"); }, cts.Token)
};
<p>try {
await Task.WhenAll(tasks);
} catch {
cts.Cancel(); // 尽早触发取消通知
throw;
}替代方案：WhenAny + 手动控制流更适合短路场景
如果你的真实需求是“任一任务失败就中止全部，并返回错误”，Task.WhenAny 更贴近意图。它返回最先完成的任务，你可以判断它是成功还是失败，再决定是否取消其余任务。
-
WhenAny本身不抛异常，你需要主动await它的结果并检查IsFaulted或IsCanceled - 记得对未完成的任务调用
Dispose()或确保它们能自然退出，避免资源泄漏 - 比起硬套
WhenAll再补取消逻辑，用WhenAny从设计上更清晰、更易测试
真正难的不是写对语法，而是分清你要的是“等全部做完再看结果”，还是“有一个不对劲就马上刹车”。前者用 WhenAll，后者别硬拗，换 WhenAny 或自建协调逻辑。
