await foreach 是流式消费异步序列，不是并行执行
await foreach用于遍历实现了
IAsyncEnumerable<t></t>的异步数据源，比如从数据库分页查询、HTTP 流式响应、或自定义的异步生成器。它按顺序等待每一项就绪后再取下一项，本质是“串行拉取 + 即时处理”。
常见误用是以为它会自动并发执行循环体——其实不会。
await foreach内部的
await只是挂起当前迭代，不启动新任务。 适合场景：内存敏感、需逐项处理、下游依赖前项结果（如日志流水线、流式解析） 错误现象：在循环体内调用
await SomeAsyncMethod(item)，但整体耗时接近各次调用之和 → 说明没并发 性能影响：无额外线程开销，但吞吐受限于单条路径延迟
await Task.WhenAll(linq) 是并发触发所有任务，再统一等待完成
你得先用 LINQ 构造出一个
Task<t>[]</t>或
IEnumerable<task>></task>，再传给
Task.WhenAll。它立刻并发启动所有任务，然后等待全部结束。
注意：
Task.WhenAll不接受
IAsyncEnumerable<t></t>，也不能直接套在
foreach上——必须显式投影为任务集合。 适合场景：独立 IO 操作（如批量 HTTP 请求、并发查 DB 主键）、追求总耗时最短 参数差异：若传入含
null的任务数组，会抛
ArgumentNullException；空集合返回已完成的
Task<t></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遇异常直接中断迭代 真正难的是权衡：并发数控制、取消传播、进度反馈——这些两者都不内置，得自己补
