await foreach 是串行拉取异步序列，Task.WhenAll 才实现并发执行；前者适用于流式处理，后者适合独立任务批量触发。
await foreach 是流式消费异步序列，不是并行执行
await foreach 用于遍历实现了 IAsyncEnumerable<T> 的异步数据源，比如从数据库分页查询、HTTP 流式响应、或自定义的异步生成器。它按顺序等待每一项就绪后再取下一项，本质是“串行拉取 + 即时处理”。
常见误用是以为它会自动并发执行循环体——其实不会。await foreach 内部的 await 只是挂起当前迭代，不启动新任务。
- 适合场景：内存敏感、需逐项处理、下游依赖前项结果（如日志流水线、流式解析）
- 错误现象：在循环体内调用
await SomeAsyncMethod(item)，但整体耗时接近各次调用之和 → 说明没并发 - 性能影响：无额外线程开销，但吞吐受限于单条路径延迟
await Task.WhenAll(linq) 是并发触发所有任务，再统一等待完成
你得先用 LINQ 构造出一个 Task<T>[] 或 IEnumerable<Task<T>>，再传给 Task.WhenAll。它立刻并发启动所有任务，然后等待全部结束。
注意：Task.WhenAll 不接受 IAsyncEnumerable<T>，也不能直接套在 foreach 上——必须显式投影为任务集合。
- 适合场景：独立 IO 操作（如批量 HTTP 请求、并发查 DB 主键）、追求总耗时最短
- 参数差异：若传入含
null的任务数组，会抛ArgumentNullException；空集合返回已完成的Task<T[]> - 风险点：未节流可能打爆连接池或触发限流（如 HttpClient 默认 6 并发）
典型错误：混淆 await foreach 和并行任务构造
下面这段代码看似“并发”，实则仍是串行：
await foreach (var item in source)
{
await ProcessItemAsync(item); // 每次都等完才进下一轮
}
而正确并发写法需要先生成任务队列：
var tasks = source.Select(async item => await ProcessItemAsync(item)).ToArray(); await Task.WhenAll(tasks);
或者更高效（避免过早 await）：
var tasks = source.Select(item => ProcessItemAsync(item)).ToArray(); await Task.WhenAll(tasks);
- 关键区别：第二段中
ProcessItemAsync(item)被立即调用并返回Task，不 await；Task.WhenAll才真正等待它们 - 容易踩的坑：在
Select里写async item => await X()会多一层状态机，且可能掩盖异常；应直接返回Task - 兼容性：.NET Core 3.0+ 支持
IAsyncEnumerable；Task.WhenAll自 .NET 4.5 就存在
选哪个？看数据源形态和执行意图
如果源头天然支持异步流（如 EF Core 5+ 的 AsAsyncEnumerable()、Channel.Reader.ReadAllAsync()），且你不想一次性加载全部数据到内存，await foreach 是唯一安全选择。
如果你有一组已知的、彼此独立的任务要跑，并且能承受并发压力，Task.WhenAll 更直接高效。
- 混合使用也常见：先
await foreach分批拉数据，每批内用Task.WhenAll并发处理 - 别忽略异常行为：
Task.WhenAll遇到任一失败会 aggregate 所有异常；await foreach遇异常直接中断迭代 - 真正难的是权衡：并发数控制、取消传播、进度反馈——这些两者都不内置，得自己补
