17370845950

await foreach 是串行拉取异步序列，Task.WhenAll 才实现并发执行；前者适用于流式处理，后者适合独立任务批量触发。

await foreach 是流式消费异步序列，不是并行执行

await foreach 用于遍历实现了 IAsyncEnumerable 的异步数据源，比如从数据库分页查询、HTTP 流式响应、或自定义的异步生成器。它按顺序等待每一项就绪后再取下一项，本质是“串行拉取 + 即时处理”。

常见误用是以为它会自动并发执行循环体——其实不会。await foreach 内部的 await 只是挂起当前迭代，不启动新任务。

• 适合场景：内存敏感、需逐项处理、下游依赖前项结果（如日志流水线、流式解析）
• 错误现象：在循环体内调用 await SomeAsyncMethod(item)，但整体耗时接近各次调用之和 → 说明没并发
• 性能影响：无额外线程开销，但吞吐受限于单条路径延迟

await Task.WhenAll(linq) 是并发触发所有任务，再统一等待完成

你得先用 LINQ 构造出一个 Task[] 或 IEnumerable>，再传给 Task.WhenAll。它立刻并发启动所有任务，然后等待全部结束。

注意：Task.WhenAll 不接受 IAsyncEnumerable，也不能直接套在 foreach 上——必须显式投影为任务集合。

• 适合场景：独立 IO 操作（如批量 HTTP 请求、并发查 DB 主键）、追求总耗时最短
• 参数差异：若传入含 null 的任务数组，会抛 ArgumentNullException；空集合返回已完成的 Task
• 风险点：未节流可能打爆连接池或触发限流（如 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 遇异常直接中断迭代
• 真正难的是权衡：并发数控制、取消传播、进度反馈——这些两者都不内置，得自己补