Task.WhenAll 适合异步 I/O 并发，不是 CPU 密集型并行
Task.WhenAll本质是等待多个
Task同时完成，它不创建新线程，也不控制执行时机——所有任务必须已启动（或在传入时立即启动）。常见误用是把它当成“并发执行多个耗时计算”，结果发现 CPU 占用没上去、总耗时不降反升。
典型适用场景：同时发起多个 HTTP 请求、读多个文件、查多个数据库。这些操作大部分时间在等 I/O，线程可以释放去做别的事。
传入的每个Task应该是真正异步的（比如用了
HttpClient.GetAsync、
File.ReadAllTextAsync），而不是包装了
Task.Run(() => { Thread.Sleep(1000); })
如果任务里混入同步阻塞代码（如 Thread.Sleep、
File.ReadAllText），会占用线程池线程，可能拖慢其他异步操作 返回的是
Task<t></t>，结果顺序与输入顺序严格一致
var tasks = new[]
{
httpClient.GetAsync("https://api1/"),
httpClient.GetAsync("https://api2/"),
httpClient.GetAsync("https://api3/")
};
var responses = await Task.WhenAll(tasks); // 三路请求真正并发，通常 1 秒内完成
Parallel.Invoke 是同步 CPU 绑定任务的并行执行工具
Parallel.Invoke会在内部使用
ThreadPool分配多个线程，强制并行执行多个
Action委托。它不返回值，也不支持
async委托——传入的每个动作都必须是同步的、CPU 密集型的。
如果你试图在里面
await，编译直接报错；如果硬写成
async void或用
.Wait()，会死锁或严重降低效率。 适合场景：图像像素处理、大量数学计算、本地 XML 解析、批量字符串转换等纯内存运算 不适用于含 I/O 的逻辑（如写文件、调 API），因为线程会被卡住，浪费线程池资源 没有内置顺序保证，各 Action 执行完成时间不确定，也不能直接获取返回值
Parallel.Invoke(
() => ProcessImage(partA),
() => ProcessImage(partB),
() => ProcessImage(partC)
); // 三个计算任务真正在多核上跑，假设每个需 800ms，总耗时约 800ms
别把 async 方法塞进 Parallel.Invoke
这是最常踩的坑：
Parallel.Invoke接收的是
Action，而
async void或
async Task方法签名不匹配。即使你绕过编译（比如用
.Wait()），也会引发线程池饥饿、死锁或异常堆积。 错误写法：
() => SomeAsyncMethod().Wait()—— 阻塞线程，失去 async 意义 错误写法：
async () => await SomeAsyncMethod()—— 编译失败，类型不兼容 正确做法：I/O 类型并发统一走
Task.WhenAll；CPU 类型才考虑
Parallel.Invoke或
Parallel.For
混合场景（比如先并发下载，再并发处理）要分两层：先
await Task.WhenAll(downloads)拿到数据，再用
Parallel.ForEach处理 byte[] 数组。
性能和可维护性差异很实际
Task.WhenAll开销极小，只是组合状态机；
Parallel.Invoke有线程调度、负载均衡、异常聚合等开销，小数据量下甚至比单线程还慢。 10 个 50ms 的 HTTP 请求：用
Task.WhenAll总耗时 ~55ms；用
Parallel.Invoke + .Wait()可能要 500ms+（线程争抢 + 阻塞） 10 个 50ms 的 CPU 计算：用
Parallel.Invoke可压满双核，总耗时 ~55ms；用
Task.WhenAll(Task.Run(...))多一层调度，略慢但可接受 调试难度：
Task.WhenAll异常堆栈清晰指向具体哪个 task；
Parallel.Invoke的异常会被包装成
AggregateException，需遍历
InnerExceptions
真正难的是判断一个方法到底是 I/O 型还是 CPU 型——看它是否频繁调系统调用、是否长时间不返回、是否依赖外部服务。这点错了，选什么并发方案都白搭。
