parallel.foreachasync专为i/o密集型异步任务设计，核心是可控并发度；不能将async lambda用于parallel.foreach，因其转为action丢弃task；必须用iasyncenumerable或显式转换；maxdegreeofparallelism控制并发异步任务数而非线程数；需手动线程安全收集结果，且异常不聚合。
Parallel.ForEachAsync 不是 Parallel.ForEach 的异步版本，也不能直接塞 async lambda 进去——它专为 I/O 密集型异步任务设计，核心价值是可控并发度，不是“让 foreach 变快”。
为什么不能把 async/await 塞进 Parallel.ForEach
你写 Parallel.ForEach(items, async item => await DoAsync(item)) 看似没问题，但编译器会静默转成 Action<t></t>，丢弃返回的 Task。结果就是：函数立即返回，异步操作在后台“裸奔”，主流程不等、不捕获异常、不保证完成——dicts.Count 为 0 就是典型表现。
-
Parallel.ForEach的body参数类型固定为Action<t></t>，不接受Func<t task></t> - 即使编译通过，实际执行的是“启动异步操作后立刻结束本轮迭代”，不是真正等待
- 没有内置取消传播、异常聚合或并发控制，极易漏错、丢数据、线程池饥饿
Parallel.ForEachAsync 必须用 IAsyncEnumerable 或显式转换
它只重载了两个签名：ForEachAsync<t>(IAsyncEnumerable<t>, ...)</t></t> 和 ForEachAsync<t>(IEnumerable<t>, ...)</t></t>。后者看似支持普通集合，但底层仍会调用 .ToAsyncEnumerable() 包装——这意味着：若你传 List<t></t>，它不会“自动变异步”，而是按需枚举 + 异步调度。
- 推荐显式构造
IAsyncEnumerable<t></t>：比如用AsyncEnumerable.Range(1, 100)或自定义 yield return IAsyncEnumerable - 传
IEnumerable<t></t>时，ForEachAsync内部会做一次同步枚举（无额外开销），但语义更清晰 - 别依赖“隐式转换”；若源是数据库查询或流式 API，优先走
IAsyncEnumerable原生路径
MaxDegreeOfParallelism 控制的是“正在运行的 async 任务数”，不是线程数
这是和 Parallel.ForEach 最本质的区别：Parallel.ForEach 的 MaxDegreeOfParallelism 限制线程池租用数；而 ForEachAsync 的同名参数控制的是“同时处于 await 等待状态的任务上限”。对 HTTP 请求、文件读写这类 I/O 操作，这才是真正影响吞吐和稳定性的关键。
- 默认值是
Environment.ProcessorCount，对 I/O 场景通常过大；建议设为10–50，视远程服务限流策略调整 - 设为
1等价于串行 async/await，适合强顺序或令牌桶场景 - 它实现的是滑动窗口模型：一个任务完成，立刻补上新任务，始终保持 ≤ N 个活跃异步操作
- 不会因某次
await时间长就卡住整个循环——别的任务照常推进
结果收集必须手动线程安全，且无法直接返回数组
ForEachAsync 返回 Task，不是 Task<t></t>。它不聚合结果，只保证所有迭代完成（或失败）。你需要自己在 body 中收集，且必须考虑并发写入安全。
- 别用
List<t>.Add()</t>—— 非线程安全，会丢数据或抛InvalidOperationException - 推荐
ConcurrentBag<t></t>（无序、高性能）或ConcurrentQueue<t></t>（FIFO） - 若需保持原始顺序，得额外维护索引或用
lock+List<t></t>，但会抵消部分并发收益 - 注意
CancellationToken传播：所有await调用都应传入ct，否则取消可能不生效
最易被忽略的一点：它不处理异常聚合。任一迭代抛出未捕获异常，整个 Task 就以 AggregateException 失败，但你拿不到具体是哪个 item 出的问题——得在 body 里加 try/catch 单独记录，或用 Task.WhenAll + 手动限流来换更细粒度控制。
