parallel.foreach仅适用于纯cpu密集型任务，如图像处理、数值计算；不适用于i/o操作，否则导致线程饥饿；需设合理maxdegreeofparallelism，避免过度并发；共享变量须线程安全；高并发i/o应改用async/await+task.whenall。
别用 Parallel.ForEach 处理 I/O 任务，它只适合 CPU 密集型场景；高并发下盲目并行反而拖垮吞吐。
什么时候该用 Parallel.ForEach？
它本质是把数据切块、分发到线程池线程上并行执行，前提是每个迭代项的处理逻辑：纯计算、无阻塞、不依赖外部服务。
- 适用：图像像素批量处理、JSON 字段校验、数值数组归一化、规则引擎单条匹配
- 不适用：HTTP 调用、数据库查询、文件读写、Redis 操作——这些都会让线程池线程卡住，引发饥饿
- 验证方法：把循环体里所有外部调用换成
Thread.Sleep(10)，如果提速明显，才说明适合并行；否则大概率是假提速、真恶化
Parallel.ForEach 的并发数怎么设才不翻车？
默认不限制并发度，会按线程池当前可用线程数动态分配，但线程池不是无限资源。CPU 核心数只是起点，不是上限。
- 计算密集型（如压缩、加密）：
MaxDegreeOfParallelism = Environment.ProcessorCount是安全起点 - 混合型（含少量内存分配或短时等待）：
Environment.ProcessorCount * 2可试，但必须压测验证 - 绝对不要设成
int.MaxValue或硬写 100+ —— 这会触发大量上下文切换，Parallel.ForEach自身开销可能超过收益 - 注意：
ParallelOptions一旦传入，就无法在运行时动态调整；若需弹性控制，请换SemaphoreSlim+Task.Run
共享变量写错，结果就错得无声无息
Parallel.ForEach 不保证执行顺序，多个线程同时写同一变量极易覆盖。常见错误包括：
- 直接往同一个
List<t></t>里Add—— 即使是ConcurrentBag<t></t>也得注意枚举时的快照语义 - 用普通
int计数器累加，结果远小于预期 —— 改用Interlocked.Increment(ref count) - 写入数组时索引算错（比如用
foreach的item而非原始索引），导致越界或错位 - 正确做法：优先用局部变量收集结果，最后用
lock或ConcurrentQueue<t></t>合并；或改用PLINQ的AsParallel().Select().ToArray()，它自动处理输出映射
比 Parallel.ForEach 更稳的大规模并发方案
真正高并发（比如每秒数千请求）不是靠“更快地跑循环”，而是分层解耦：
- I/O 类任务（调 API、查 DB）：全走
async/await+Task.WhenAll，配合SemaphoreSlim控制并发数（如限制最多 50 个 HTTP 请求同时发出） - CPU 类任务（解析、转换、校验）：仍可用
Parallel.ForEach，但必须隔离在独立线程池（用TaskScheduler.FromCurrentSynchronizationContext()不行，得自建ConcurrentExclusiveSchedulerPair） - 混合负载：用
Channel<t></t>做生产者-消费者队列，上游异步接收任务，下游用固定数量的Parallel.ForEach工作线程消费 —— 这样既控流又避免线程风暴
最常被忽略的一点：Parallel.ForEach 的异常会包装成 AggregateException，且默认只抛第一个内层异常；不手动遍历 InnerExceptions，你根本不知道哪几条数据失败了。
