GroupBy多字段分组应使用匿名类型或值元组以确保正确性；避免用未重写Equals/GetHashCode的普通类作键；取首条需防null并考虑排序稳定性；性能敏感时应缓存IGrouping或用Aggregate；EF Core中导航属性分组需版本支持或改用Select/Join。
GroupBy 多字段分组必须用匿名类型或元组
直接写 GroupBy(x => new { x.Category, x.Status }) 是最常用也最安全的方式。C# 编译器会为匿名类型自动生成 Equals 和 GetHashCode，保证分组逻辑正确。如果手写类但没重载这两个方法，分组会出错——比如相同字段值被拆成多个组。
替代方案是用值元组：GroupBy(x => (x.Category, x.Status))，语法更轻量，且 .NET Core 2.0+ 原生支持元组的相等性比较，无需额外处理。
常见错误：用普通类实例做键（如 GroupBy(x => new GroupKey(x.Category, x.Status))），但 GroupKey 没重写 Equals/GetHashCode，结果分组数量翻倍、统计值错乱。
分组后取每组第一条数据要小心 null
经常有人写 group.First() 或 group.FirstOrDefault() 拿“代表项”，但实际场景中，group 是 IGrouping<k t></k>，它本身不为空，但内部元素可能为空（比如源集合含 null 元素且没过滤）。若原始数据有 null，又没提前 .Where(x => x != null)，First() 会抛 InvalidOperationException。
稳妥做法是：
- 先确保源数据非空：
data.Where(x => x != null).GroupBy(...) - 用
FirstOrDefault()并判空：group.FirstOrDefault() ?? new DefaultItem() - 若需稳定取首条，建议加
.OrderBy(x => x.Id).First()显式排序，避免依赖原始顺序（LINQ to Objects 通常保持顺序，但 LINQ to Entities 不一定）
性能敏感时避免在 GroupBy 后反复遍历 group
IGrouping 是延迟执行的，每次调用 Count()、Sum()、ToList() 都可能重新枚举整个子集。比如写 new { Key = g.Key, Count = g.Count(), Total = g.Sum(x => x.Amount), Avg = g.Average(x => x.Amount) }，底层会对 g 遍历 3 次。
优化方式：
- 用
g.ToList()缓存一次：var list = g.ToList(); new { Key = g.Key, Count = list.Count, Total = list.Sum(x => x.Amount), ... } - 或用
Aggregate单次遍历计算多个值（适合复杂聚合逻辑） - 对数据库查询（LINQ to Entities），尽量让聚合下推到 SQL，避免把整组数据拉到内存再算——检查生成的 SQL 是否含
GROUP BY和SUM/COUNT，而不是SELECT *后在 C# 里分组
GroupBy 在 EF Core 中不能直接对导航属性分组
比如想按 Order.Customer.Name 分组，EF Core 6+ 才支持这种写法；老版本会报 System.InvalidOperationException: The LINQ expression could not be translated。根本原因是导航属性展开后无法映射为 SQL 的 GROUP BY 字段。
可行解法：
- 提前
Select出需要的字段再分组：ctx.Orders.Select(o => new { o.Id, CustomerName = o.Customer.Name }).GroupBy(x => x.CustomerName) - 用
Join显式关联：ctx.Orders.Join(ctx.Customers, o => o.CustomerId, c => c.Id, (o, c) => new { o, c }).GroupBy(x => x.c.Name) - 若必须用导航属性且版本低，改用原始 SQL 或存储过程
注意：EF Core 分组结果不能直接调用 AsNoTracking()，得在 GroupBy 前加，否则会忽略跟踪行为，影响后续变更检测逻辑。
