AsParallel()仅在数据量大（≥10k）、纯CPU密集型且无共享状态时才可能加速；小数据、I/O操作、UI调用、忽略顺序或误用WithDegreeOfParallelism/AsOrdered()/Aggregate/ForEach时反而更慢甚至崩溃。
AsParallel() 不是“加了就快”的银弹，它只在数据量大（通常 >10k）、计算密集、且无共享状态时才可能提速；小数据、I/O 操作、UI 线程直调、或忽略顺序要求时，反而更慢甚至崩溃。
AsParallel() 什么时候真能加速？
它不是自动优化器，而是并行执行开关——是否提速，取决于你喂给它的任务类型：
- 真正受益的场景：
Math.Pow、字符串正则匹配、哈希计算、图像像素变换等纯 CPU 密集型操作，输入集合 ≥ 10k 元素 - 必然拖慢的场景：
File.ReadAllText(x)（磁盘争抢）、httpClient.GetAsync(x).Result（阻塞线程池）、Console.WriteLine（锁竞争） - 看似合理实则危险：
static Dictionary<string, object>在 lambda 中读写——PLINQ 不保护你的静态变量
不配 WithDegreeOfParallelism 就别用 AsParallel()
默认行为是让 PLINQ 自己决定并发度，往往等于 Environment.ProcessorCount，但实际中这常导致上下文切换压垮性能。尤其在 4–8 核常见机器上，盲目全开反而吞吐下降。
- 推荐设为
Environment.ProcessorCount - 1，留一个核给系统调度或其他后台任务 - 若任务本身含短时等待（如
Thread.Sleep(1)），可进一步下调到 2–4，避免线程空转 - 千万别写
.AsParallel().WithDegreeOfParallelism(100)—— 这不是“越多越好”，是制造线程风暴
AsOrdered() 是性能杀手，除非你真需要顺序
PLINQ 默认打乱处理顺序以最大化吞吐，AsOrdered() 强制维持原始索引顺序，代价是引入排序缓冲区和额外同步开销，吞吐常降 20%~40%。
- 必须加的情况：结果要和输入一一映射（比如批量解析后按原位置写回 Excel）、分页计算需保序
- 不该加的情况：只是过滤或转换后
ToList()，后续再OrderBy—— 那不如串行做完再排 - 加了
AsOrdered()后，Take(5)才可能真正短路；否则 PLINQ 可能仍遍历全部分片
Aggregate 和 ForEach 是最容易翻车的两个操作符
它们在 PLINQ 下语义变化最大，不改写法几乎必出错：
-
Aggregate()的两参数重载（.Aggregate(seed, (acc, x) => ...)）在并行下不安全，必须用三参数版本：.Aggregate(seed, (acc, x) => ..., (a, b) => a + b)，最后一个函数负责合并各线程局部结果 -
ForEach()不返回值，也不保证线程安全——往List<T>里Add()必崩；要收集结果，改用ConcurrentBag<T>或先Select().ToArray()再统一处理 -
First()虽支持短路，但启动开销高；若目标元素大概率在前 100 个里，串行Where(...).First()更稳
真正难的不是写对语法，而是判断“这个查询到底该不该并行”——数据规模、计算性质、副作用范围、下游消费方式，缺一不可。很多性能问题，根源不在代码写错，而在过早、过泛地套用 AsParallel()。
