Count() 返回0是设计行为而非错误，但需警惕多次枚举导致的数据源耗尽或过滤条件误写（如=代替==）；Sum() 对空可空类型集合抛异常，应改用GetValueOrDefault()或空值处理。
Count() 为什么返回 0 却不报错？检查数据源是否为空或被提前消费
Count() 在空集合上安全返回 0，这是设计行为，不是 bug。但常见误判源于两个陷阱：一是 IEnumerable 被多次枚举（比如来自 yield return 或未缓存的查询），第二次调用 Count() 可能因数据源已耗尽而返回 0；二是过滤条件写错，比如 Where(x => x.Id = 5)（用了赋值=而非比较==），导致实际无匹配项。
实操建议：
- 对可能被多次使用的查询结果，先转成
List或ToArray()再计数，例如var list = data.ToList(); int c = list.Count; - 调试时直接在
Count()前加断点，用“快速监视”看原始数据和Where后的中间结果 - 避免在循环内反复调用
Count()—— 它对List是 O(1)，但对IQueryable（如 EF Core）会触发 SQL 查询，性能陡降
Sum() 报错 “Nullable object must have a value” 怎么办？
这是最常遇到的异常，对应错误信息：System.InvalidOperationException: Nullable object must have a value. 根本原因是调用了 Sum() 的泛型重载（如 Sum(x => x.Price)），而该属性是 decimal? 或 int? 类型，且集合为空或所有值为 null。
实操建议：
- 明确使用可空类型的求和重载：改用
Sum(x => x.Price.GetValueOrDefault())，或先过滤非空Where(x => x.Price.HasValue).Sum(x => x.Price.Value) - EF Core 中，
Sum()空集合默认返回null（数据库语义），所以服务端代码必须处理 null，例如query.Sum(x => x.Amount) ?? 0m - 不要依赖
DefaultIfEmpty(0).Sum()—— 它在 LINQ to Objects 中有效，但在 EF Core 里可能生成意外的 LEFT JOIN，影响性能和结果
Count 和 Sum 在 IQueryable vs IEnumerable 下行为差异极大
同一个表达式，在内存集合（IEnumerable）和数据库查询（IQueryable，如 EF Core）中执行逻辑完全不同。比如 data.Where(x => x.Status == "A").Count()：前者遍历全部对象再计数；后者翻译成 SELECT COUNT(*) FROM ... WHERE Status = 'A'，只传回一个数字。
实操建议：
- 确认类型：用
var q = context.Orders.AsQueryable();显式控制起点；若已调用.ToList()，后续所有 LINQ 都是内存操作，Count()不再走 SQL - 避免混合使用：不要在
IQueryable上先.Select(x => new { x.Id, x.Total })再.Count()，这会让 EF 尝试把整个投影结果 COUNT，容易报错或低效 - 需要精确控制 SQL 时，EF Core 9+ 支持
CountAsync(x => x.Active)直接下推谓词，比先Where再Count更清晰
复杂条件统计：别硬套 Count/Sum，优先考虑 GroupBy + Select
当需求变成“每个部门的员工数、平均薪资、最高奖金”，硬写多个 Count() 和 Sum() 不仅难读，还可能触发 N+1 查询。这时 GroupBy 是更自然的表达方式。
实操建议：
- 单次分组聚合：例如
orders.GroupBy(o => o.Category).Select(g => new { Cat = g.Key, Total = g.Sum(x => x.Amount), Count = g.Count() }) - 条件聚合用
Sum(x => x.Status == "Shipped" ? x.Amount : 0)替代嵌套Where().Sum()，EF Core 能更好翻译成 SQL 的CASE WHEN - 注意
Count()在分组内是g.Count()（组内元素数），不是g.Count（语法错误）—— 少个括号就会编译失败
真正卡住人的往往不是语法，而是没意识到 Count() 在 EF 中是数据库函数，而在内存里是遍历；也不是不会写 Sum()，而是忘了它对空集合在可空类型上的崩溃边界。多看一眼 var 实际类型，比背十个例子管用。
