不会阻塞调用线程但串行执行；应改用 Task.WhenAll 并发执行，避免循环中捕获变量导致内存压力。
循环里直接 await Task.Run() 会阻塞线程吗
不会阻塞调用线程，但会串行执行——这是最常被误解的一点。很多人以为加了 await 就自动并行了，其实只是把同步等待换成了异步等待，逻辑仍是“一个接一个”跑。
典型错误写法：
foreach (var item in items)
{
await ProcessAsync(item); // 每次都等上一个完成才开始下一个
}
- 适用场景：必须按顺序处理（如依赖前一步结果、写入有序日志）
- 性能影响：总耗时 ≈ 所有
ProcessAsync耗时之和，毫无并发收益 - 容易踩的坑：误以为用了
async/await就等于“快了”，结果压测发现吞吐量没变
想并发执行多个异步操作，该用 Task.WhenAll 还是 Task.WhenAny
Task.WhenAll 是绝大多数情况的正确选择；Task.WhenAny 只在“只要一个完成就继续”的特殊场景才用，比如超时兜底或竞速请求。
正确并发写法：
var tasks = items.Select(item => ProcessAsync(item)); await Task.WhenAll(tasks); // 同时启动全部，等全部结束
-
Task.WhenAll返回Task<t></t>，结果顺序与输入顺序一致 - 如果任一任务抛异常，
await Task.WhenAll(...)会直接 throw 第一个异常（其余异常藏在AggregateException.InnerExceptions里） - 别用
Task.Run(() => { ... await ... })包一层——这是反模式，会额外调度线程且掩盖 async 上下文
循环中创建大量 Task 导致内存暴涨或 GC 压力大怎么办
不是 Task 本身占内存，而是未完成的异步状态机 + 持有的闭包变量（尤其是循环变量捕获）导致对象长期存活。
常见翻车点：
for (int i = 0; i < 10000; i++)
{
tasks.Add(ProcessAsync(data[i])); // 看似没问题
}
- 问题根源：如果
ProcessAsync内部有延迟（如await Task.Delay(1000)），这 10000 个 Task 对象及其上下文会持续驻留内存 - 缓解方案：分批执行，用
Chunk（.NET 6+）或手动切片，每批 100–500 个：foreach (var batch in items.Chunk(200)) { await Task.WhenAll(batch.Select(ProcessAsync)); } - 注意：别在循环里反复 new HttpClient 实例——复用单例，否则 DNS 缓存失效 + 连接池打爆
await foreach 和 IAsyncEnumerable 在循环中的实际表现
它解决的是“数据源本身是流式异步产生”的问题，不是用来替代普通 foreach + Task.WhenAll 的。强行套用反而增加复杂度。
真实适用场景：数据库游标分页查询、实时消息流、大文件分块读取。
await foreach (var item in GetItemsAsync()) // GetItemsAsync 返回 IAsyncEnumerable<T>
{
await HandleAsync(item);
}
- 这个循环是真正逐个 await 的，不并发，也不缓存全部结果
- 如果
GetItemsAsync()内部用了yield return+await，那每次迭代都可能触发一次远程调用 - 别把它当成
Task.WhenAll的语法糖——两者定位完全不同，混用会导致语义混乱和性能误判
异步循环真正的复杂点不在语法，而在你是否清楚每个 await 背后是 IO 等待、CPU 计算，还是单纯的状态机切换。很多人卡住，是因为没打开 dotnet trace 看过实际线程调度和等待事件分布。
