命名元组更安全，需显式声明字段名如(Id: x.UserId, Status: x.OrderStatus)；匿名类型无法复用，位置元组与命名元组Equals不兼容；空集合时Sum/Average需转可空类型避免异常。
GroupBy 多字段分组时，匿名类型 vs 元组哪个更安全？
用 GroupBy 按多个字段分组，最常见写法是传入匿名类型（new { a, b }）或 C# 7+ 的元组（(a, b)）。两者都能工作，但行为不同：匿名类型在每次调用时生成新类型，无法跨方法复用；元组虽简洁，但若字段名不一致（比如 (x.Id, x.Name) 和 (x.UserId, x.FullName)），即使结构相同也会被视为不同类型，导致分组键比较失败。
- 生产环境优先用命名元组，显式声明字段名：
GroupBy(x => (Id: x.UserId, Status: x.OrderStatus)) - 避免混用位置元组（
(x.UserId, x.Status)）和命名元组，它们的Equals实现不兼容 - 若需缓存分组逻辑或单元测试断言，定义专用的
record类更可控，比如record OrderKey(int UserId, string Status)
聚合统计中 Count()、Sum()、Average() 的空集合陷阱
Count() 对空分组返回 0，安全；但 Sum() 和 Average() 在分组内无元素时会抛出 InvalidOperationException: Sequence contains no elements。这不是 LINQ 延迟执行的问题，而是这些聚合函数的契约决定的——它们要求至少一个值。
- 用
Sum(x => (decimal?)x.Amount) ?? 0将结果转为可空类型再空合并，绕过异常 -
Average()同理：Average(x => (double?)x.Score) ?? 0 - 若业务上“无数据”需区别于“0值”，保留可空类型并显式检查
hasValue，而不是盲目?? 0
OrderBy + GroupBy 顺序错了会导致性能暴跌
先 OrderBy 再 GroupBy 是常见误区。LINQ to Objects 下看似可行，但实际会强制全部数据进入内存并排序，之后才分组；而多数场景只需要每组内取 TopN 或按某字段排序后聚合，完全没必要全局排序。
- 正确做法是分组后对每组单独处理：
GroupBy(...).Select(g => new { Key = g.Key, MaxTime = g.Max(x => x.CreatedAt) }) - 若真需“按分组最大值排序”，用
GroupBy(...).OrderBy(g => g.Max(x => x.Value)).ThenBy(...)，而非先OrderBy再GroupBy - EF Core 中该错误会直接翻译成低效 SQL（如先
ORDER BY再GROUP BY），可能触发全表扫描
GroupJoin 实现左连接分组统计时，DefaultIfEmpty() 的坑
做主表+从表的左连接并统计从表数量（例如“每个用户订单数，含 0”），常组合 GroupJoin + DefaultIfEmpty()。但 DefaultIfEmpty() 若不传参，默认填充 null，后续调用 Count() 会把 null 当作一个元素计数，导致结果多 1。
- 必须显式传参：
DefaultIfEmpty(new Order())或更推荐DefaultIfEmpty(null)，然后在Select中用g.Where(x => x != null).Count() - 更简洁写法：
GroupJoin(...).Select(g => new { User = g.Key, OrderCount = g.Count(x => x != null) }) - EF Core 6+ 支持
Count()直接忽略 null，但低版本仍需手动过滤
多字段分组真正难的不是语法，而是键相等性判断的隐式规则、空值传播路径、以及 IQueryable 到 SQL 翻译时的语义偏移——这些地方一错，结果不对或性能崩掉，都很难一眼看出来。
