GroupBy 按 keySelector 返回的键是否相等分组，依赖 Equals() 和 GetHashCode()；引用类型默认引用相等，需重载或传 IEqualityComparer；null 键归为一组，空列表返回空结果，延迟执行但分组后内存驻留。
GroupBy 在 C# 里到底按什么分组？
它不是按“值相等”粗暴分，而是按 keySelector 返回的键（key）是否“相等”来分——这个“相等”默认走 Equals() + GetHashCode()，对引用类型就是引用相等，除非你重载或传自定义 IEqualityComparer<tkey></tkey>。
常见错误现象：GroupBy(x => x.Name) 对两个内容相同但不同实例的字符串对象能分到一组（因为 string 重载了），但对自定义类的属性（比如 Person.Id 是 int 没问题，Person.Address 是未重载的引用类型就可能分错）。
- 如果分组键是简单类型（
int、string、DateTime），基本不会出问题 - 如果键是匿名类型或元组（如
x => new { x.Category, x.Status }），C# 自动为它们实现了值语义，安全 - 如果键是你自己的类，又没重写
Equals/GetHashCode，那就得手动传IEqualityComparer，否则每组只含一个元素
空集合 or null 元素导致 GroupBy 崩溃？
不会崩，但行为容易误判：GroupBy 本身不拒绝 null 元素，但如果 keySelector 返回 null（比如 x => x?.Tag 且 x.Tag 为 null），那所有 null 键会被归到同一组——这组的键是 null，不是空字符串或默认值。
使用场景：处理可能缺失字段的日志记录、DTO 转换后的列表。
-
list.GroupBy(x => x?.Type ?? "Unknown")更可控，避免null键带来后续foreach或FirstOrDefault(g => g.Key == null)的困惑 - 如果原始列表是
null，调用.GroupBy()会直接抛ArgumentNullException，务必前置判空 - 空集合（
new List<t>()</t>）调用GroupBy返回空的IEnumerable<igrouping>></igrouping>，可安全遍历（循环体不执行）
GroupBy 后怎么取每组第一个/最后一个元素？
别在 GroupBy 后立刻用 Select(g => g.First()) —— 这会触发全部分组的枚举，而且如果某组为空（理论上不会，但配合 Where 等过滤后可能出现），会抛异常。更稳妥的是用 g.FirstOrDefault()。
性能影响：所有 GroupBy 都是延迟执行，但一旦你调用 ToList()、Count() 或遍历每一组的 g.ToList()，就会真正分组并缓存结果；反复访问同一组的 g 不会重复计算。
- 取每组最新一条：
list.GroupBy(x => x.Category).Select(g => g.OrderByDescending(y => y.CreatedAt).First()) - 想避免排序开销？先用
Aggregate手动找最大值，或改用MaxBy（.NET 6+）：g.MaxBy(y => y.CreatedAt) - 不要写
g.First().Property去取字段再分组——那是先取值再分组，逻辑已变，不是按原对象分组
用 GroupBy 做分页聚合时为什么内存暴涨？
因为 GroupBy 默认实现会把整个源序列读入内存，构建内部哈希表，每组都持有对原始元素的引用。如果你对百万级 List<logentry></logentry> 分组，又没及时释放引用，GC 压力会明显上升。
兼容性注意：.NET Core 3.0+ 和 .NET 5+ 对大集合做了部分优化，但本质仍是内存驻留操作。
- 真要处理超大数据流？放弃
GroupBy，改用Lookup（一次性构建，只读）或手写字典 +foreach累积，控制生命周期 - 如果只是统计数量，别用
GroupBy(x => x.Type).Select(g => new { Type = g.Key, Count = g.Count() })，直接list.GroupBy(x => x.Type).Select(g => (g.Key, g.Count()))更轻量 - 调试时发现分组后内存没释放？检查是否把
IGrouping结果存到了静态字段或长生命周期对象里——这是最常被忽略的强引用泄漏点
