Sum/Max/Min/Average 调用需确保类型支持运算：数值类型可直接用，引用类型须提供选择器；空集合时Sum返回0而Max/Min/Average抛异常，应优先用DefaultIfEmpty()或Any()防护；注意decimal精度优于double，避免混用。
Sum/Max/Min/Average 聚合函数怎么写才不报错
直接调用 Sum、Max、Min、Average 前，必须确保集合元素类型支持对应运算。比如对 List 直接调用 Sum() 会编译失败——字符串没有定义加法重载。
常见错误现象：CS1061 “IEnumerable 或运行时报 InvalidOperationException: Sequence contains no elements。
- 数值类型（
int、double、decimal）可直接用，如list.Sum() - 引用类型需提供选择器，如
users.Sum(u => u.Age)，否则编译不过 - 空集合调用
Max/Min会抛异常；Sum和Average对空集合行为不同：Sum返回 0（对数值），Average抛异常 - 若不确定是否为空，优先用
DefaultIfEmpty(0).Sum()或先检查Any()
聚合空集合时为什么 Max 报错而 Sum 不报
这是 LINQ 设计上的语义差异：Sum 默认有“零值”概念（整数和为 0，浮点和为 0.0），而 Max 和 Min 没有天然的默认值——最大值不能凭空定义为 0 或 int.MinValue，否则可能掩盖逻辑错误。
使用场景：处理数据库查询结果或 API 返回列表时，常遇到空数据。别依赖 try-catch 来兜底，效率低且掩盖问题。
- 安全取最大值：
numbers.DefaultIfEmpty().Max()→ 返回default(int)即 0；若想区分“空”和“全为 0”，改用numbers.Any() ? numbers.Max() : null（返回int?） -
Average同样严格：空集合必抛InvalidOperationException，必须提前防护 - 注意泛型约束：对
IEnumerable，只有T实现了IComparable才能用Max/Min；数值类型都满足，但自定义类需手动实现
用 Select + 聚合组合时参数选错导致性能下降
写 list.Select(x => x.Price).Sum() 看似自然，但如果 Price 是计算属性（比如每次 get 都查数据库或做复杂运算），就会重复执行 N 次——Select 是延迟执行，但聚合时仍会遍历并触发每个 get_Price。
更隐蔽的问题是：如果源是 IQueryable（比如 EF Core 的 DbSet），Select(x => x.Price).Sum() 能转成 SQL，但 Sum(x => x.Price) 更简洁且语义更清晰，生成的 SQL 完全一致。
- 优先用带 selector 的重载：
list.Sum(x => x.Price)，而非先Select再聚合 - 避免在 selector 中写副作用逻辑（如日志、修改状态），LINQ 可能多次枚举或优化掉
- 对
IQueryable，确保聚合表达式能被翻译；像Sum(x => MyHelper.Calc(x))会报“无法转换为 SQL”
decimal 和 double 聚合结果精度不一致怎么办
Sum 和 Average 对 decimal 和 double 返回类型不同：输入是 decimal，结果就是 decimal；输入是 double，结果就是 double。但 double 累加存在浮点误差，比如 0.1 + 0.2 ≠ 0.3。
财务、计费等场景必须用 decimal，否则小误差会累积放大。别因为“都是数字”就混用。
- 确认源数据类型：EF Core 映射 decimal 字段时，确保 C# 属性是
decimal，不是double - 强制转换要谨慎：
list.Select(x => (decimal)x.PriceDouble).Sum()会在内存中转，失去 IQueryable 优化机会 - 聚合后不要轻易再转类型：比如
(double)list.Sum(x => x.Amount)可能丢失精度，且无必要
聚合操作看着简单，但空集合处理、类型匹配、精度选择这三处最容易漏掉细节。尤其在从数据库拉数据后直接聚合时，IQueryable 和 IEnumerable 的行为差异会让问题延迟暴露。
