PLINQ异常统一包装为AggregateException，必须用catch(AggregateException)并调用Flatten()遍历InnerExceptions；或在lambda内捕获并结构化返回结果。
PLINQ 中异常会被包装成 AggregateException
PLINQ 并行执行多个数据项，一旦任一任务抛出异常，它不会立即中断整个查询，而是收集所有发生的异常并统一抛出一个 AggregateException。直接 catch (Exception) 会漏掉实际错误类型，必须显式捕获 AggregateException 并遍历其 InnerExceptions 才能定位真实问题。
- 常见错误现象：只写
catch (Exception e)，结果看到的是 “One or more errors occurred”，但看不到原始异常堆栈和类型 - 正确做法是始终用
catch (AggregateException ae)，再检查ae.InnerExceptions - 注意：即使只有一个线程出错，PLINQ 仍会包装为
AggregateException，不是可选行为
使用 Try...Catch 在 lambda 内部捕获更可控
如果只想跳过个别失败项、继续处理其余数据（比如解析某条 JSON 失败不影响其他记录），应在 PLINQ 的委托内部做异常防护，而不是依赖外层 AggregateException。这避免了查询提前终止，也省去拆包逻辑。
- 适用场景：ETL 流水线、日志批量处理、API 批量调用等容错要求高的地方
- 不推荐在
Select或Where中 throw 异常后靠外层 catch —— 效率低且语义不清 - 可用
Result模式或(T, Exception)元组封装每个项的执行结果
var results = source.AsParallel()
.Select(item => {
try {
return new { Success = true, Value = ExpensiveTransform(item) };
}
catch (FormatException ex) {
return new { Success = false, Error = ex.Message };
}
catch (Exception ex) {
return new { Success = false, Error = $"Unknown: {ex.GetType().Name}" };
}
})
.ToList();
WithExecutionMode(ParallelExecutionMode.ForceParallelism) 不影响异常行为
有人误以为设置强制并行就能改变异常传播方式，其实不然。ForceParallelism 只影响是否启用并行（绕过 PLINQ 的自动串行优化判断），对异常包装机制毫无影响。所有 PLINQ 查询——无论是否强制并行——都统一走 AggregateException 路径。
- 真正影响异常可见性的，是“在哪一层捕获”：在 lambda 里捕获 → 局部处理；在外层捕获 → 全局聚合
-
WithCancellation(cancellationToken)会引发OperationCanceledException，它也会被包进AggregateException，需特别检查ae.InnerExceptions.OfType() - 调试时建议开启“仅我的代码”，否则容易在
System.Threading.Tasks内部断点卡住
嵌套 PLINQ 或混合 Task.Run 会让异常嵌套更深
如果在 PLINQ 的 Select 中又调用另一个 AsParallel()，或混用 Task.Run(() => {...}).Wait()，异常可能被多层 AggregateException 包裹。此时 ae.Flatten() 是必备操作，否则遍历 InnerExceptions 只能看到第一层包装。
-
ae.Flatten()会递归展开所有嵌套的AggregateException，返回扁平化的InnerExceptions列表 - 不要手动写递归展开逻辑，PLINQ 场景下几乎总是需要
Flatten() - 若需区分异常来源（如 IO vs 计算），建议在内部捕获时添加上下文标记，而不是依赖堆栈推断
try {
var data = source.AsParallel().Select(x => HeavyComputation(x)).ToArray();
}
catch (AggregateException ae) {
foreach (var ex in ae.Flatten().InnerExceptions) {
Console.WriteLine($"{ex.GetType().Name}: {ex.Message}");
}
}
PLINQ 的异常处理核心就两条：要么在委托内吞掉并结构化返回，要么在外层用 AggregateException + Flatten() 拆解。没有“自动展开”或“按顺序抛出”的捷径，忽略这点就会在生产环境里反复查不到原始错误。 
