AsParallel() 仅在大数据量、计算密集且元素处理独立时才可能提升性能；小集合或含副作用、不支持操作符（如TakeWhile）会失效或降级，并发需避免共享变量，应优先用Aggregate()等线程安全方式。
AsParallel() 不会自动让所有 LINQ 查询变快
并行执行不是银弹，AsParallel() 只在数据量大、计算密集、且各元素处理相互独立时才可能带来收益。小集合（比如 HttpClient）、或本身已含锁/共享状态的逻辑，反而因线程调度、同步开销和分区成本而显著变慢。
- 默认分区策略（
Partitioning）可能不均衡，尤其对非索引结构（如LinkedList或自定义枚举器） - 查询中若含
ToList()、ToArray()等强制立即执行操作，会触发完整并行计算，但后续链式调用（如再接.Where()）仍走并行路径——这点常被误认为“断掉了并行” - 调试模式下并行查询堆栈混乱，异常位置难定位；建议生产环境开启
PLINQ的异常聚合控制（见下一点）
异常处理必须显式配置 WithExecutionMode(ParallelExecutionMode.ForceParallelism) 和 WithMergeOptions()
PLINQ 默认在检测到潜在问题（如某些操作符不支持并行）时自动回退到串行执行，且异常会被包装为 AggregateException。若不干预，你可能收不到预期异常，或无法区分哪个元素出错。
- 用
.WithExecutionMode(ParallelExecutionMode.ForceParallelism)强制并行，避免静默降级 - 用
.WithMergeOptions(ParallelMergeOptions.NotBuffered)让结果流式输出，减少内存堆积（尤其配合foreach遍历时） - 捕获
AggregateException后，需遍历.InnerExceptions才能拿到原始错误，例如空引用或除零异常
try
{
var result = source.AsParallel()
.WithExecutionMode(ParallelExecutionMode.ForceParallelism)
.WithMergeOptions(ParallelMergeOptions.NotBuffered)
.Select(x => 100 / x) // 可能抛 DivideByZeroException
.ToList();
}
catch (AggregateException ex)
{
foreach (var inner in ex.InnerExceptions)
{
Console.WriteLine(inner.Message); // 打印具体哪个 x 导致失败
}
}共享变量和副作用是最大雷区
PLINQ 会把数据分块分发到多个线程执行，任何在 Select、Where 等委托中修改外部变量（如 int counter = 0; ... .Select(x => { counter++; return x * 2; })）的行为都是未定义的：计数不准、竞态、甚至死锁都可能发生。
- 禁止在 lambda 中读写类字段、静态变量、闭包捕获的局部变量（除非加锁或用线程安全类型，如
ConcurrentBag） - 若真需累积状态（如统计、日志），改用
.Aggregate()的三参数重载，它明确分离“局部累加”和“全局合并”阶段 -
ForEach()是唯一允许副作用的操作符，但它不返回结果，且不保证执行顺序——别指望它替代Select()
某些标准查询操作符不支持并行或表现异常
不是所有 LINQ 方法都能被 PLINQ 安全加速。OrderBy() 和 ThenBy() 支持，但 TakeWhile()、SkipWhile()、First()（无谓语）、Last() 在并行下语义模糊（“第一个”指原始顺序第一个？还是任意线程最先算完的那个？），PLINQ 会强制串行化这些操作，导致整条查询链降级。
-
Distinct()并行版依赖哈希分区，若GetHashCode()实现不合理（如永远返回同一值），性能会崩坏 -
GroupBy()并行效率高度依赖键分布；倾斜键（如 99% 元素 key == "A"）会让一个线程干所有活，其余空转 - 自定义
IEqualityComparer必须是无状态、线程安全的；否则Contains()或Join()可能出错
实际用 AsParallel() 前，先跑个对比基准（Stopwatch 测串行 vs 并行耗时），再检查是否真有 CPU 占用飙升、线程池队列增长等并行特征——很多“以为并行了”的场景，其实只是加了 AsParallel() 但没生效。
