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<operationcanceledexception>()</operationcanceledexception>调试时建议开启“仅我的代码”，否则容易在
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()拆解。没有“自动展开”或“按顺序抛出”的捷径，忽略这点就会在生产环境里反复查不到原始错误。
