C#怎么使用LINQ查询_C#如何使用LINQ对集合进行筛选排序分组【基础】

先说几个核心判断：LINQ 用起来确实方便，但坑也不少。很多问题并不是你语法写错了，而是对执行机制、数据源特性、以及操作符之间的微妙差异缺少预判。下面这几种情况，几乎每个用过 LINQ 的开发者都遇到过，值得逐一拆开来看。

用 Where 筛选时，别直接写 null 判断条件

最典型的例子就是 list.Where(x => x.Name != null && x.Name.Contains("a"))。看似没问题，但一旦 x 本身为 null，毫无悬念地就会抛出一个 NullReferenceException。在 EF Core 这类数据库查询场景下，null 检查会被正常翻译成 SQL，但换成内存集合（比如 List），编译器可不会为你做自动防御。

• 安全写法：先用 OfType() 把 null 元素过滤掉，或者显式加上 Where(x => x != null) 前置过滤。
• EF Core 下尤其要注意：Where(x => x.Name?.Length > 0) 这种写法，空条件运算符 ? 很可能无法翻译成 SQL，一旦触发客户端求值（Client Evaluation），性能会急剧下降，甚至直接报错。
• 字符串比较别忽略文化敏感性：Contains("A", StringComparison.OrdinalIgnoreCase) 比默认的写法可靠得多。

OrderBy 和 ThenBy 的链式调用顺序不能反

OrderBy 负责主排序，之后的 ThenBy（升序）或 ThenByDescending（降序）才构成多级排序。如果误把第二个条件也写成 OrderBy，前面的排序结果会被直接覆盖——因为每次 OrderBy 都会返回一个新序列并重新排序。

• 正确写法：list.OrderBy(x => x.Age).ThenBy(x => x.Name)
• 错误写法：list.OrderBy(x => x.Age).OrderBy(x => x.Name) —— 最终只按 Name 排序，Age 完全失效。
• 升序/降序混用示例：OrderBy(x => x.Department).ThenByDescending(x => x.Salary)
• 对大集合排序前，先确认字段是否已经建了索引（比如数据库字段）。内存中排序没有索引优化，O(n log n) 的开销不是开玩笑的。

用 GroupBy 分组后，别只拿个 Key 就收工

GroupBy 返回的是 IEnumerable>，每个 IGrouping 既是一个 IEnumerable，又带一个 Key 属性。新手常犯的错误是只取 g.Key，却忘了分组内的原始元素需要显式枚举——比如用 g.ToList() 或 g.Count() 才能拿到真正的数据。

• 典型误用：var groups = list.GroupBy(x => x.Type); foreach (var g in groups) Console.WriteLine(g.Key); —— 只打印了分组键，数据完全没处理。
• 常用组合：GroupBy(...).Select(g => new { Type = g.Key, Count = g.Count(), Items = g.ToList() })
• EF Core 中慎用 GroupBy 后接复杂投影（比如 new { ... }）。部分表达式无法翻译成 SQL，会触发客户端分组（Client Evaluation），导致全量数据拉到内存再分组，网络和内存开销瞬间暴涨。

延迟执行不是“永远不执行”，ToList/ToArray 才真正触发

所有 LINQ 查询操作符（Where、OrderBy、GroupBy）返回的都是 IQueryable 或 IEnumerable，它们仅仅是一个“查询定义”，并不会立刻执行。真正开始干活，是在你开始遍历（比如 foreach），或者调用强制执行方法的时候。

• 常见陷阱：反复调用同一个查询变量。var q = data.Where(...); var a = q.Count(); var b = q.ToList(); —— 这段代码会让数据库被查两次，或者内存集合被遍历两次。
• 解决办法：如果结果需要多次使用，先 .ToList() 或 .ToArray() 把它落地为具体集合。
• 注意 Count() 和 Any() 的差异：对数据库而言，Any() 会生成 EXISTS 语句，比 Count() > 0 高效得多；对内存集合，Any() 可以提前退出，而 Count() 必须老老实实遍历完所有元素。

实际写代码时，最容易忽略的不是语法本身，而是执行时机与数据源类型的耦合关系。同一段 LINQ，在 List 上跑得飞快，换到 EF Core 的 IQueryable 上，可能因为某个函数无法翻译而直接崩在运行时，或者悄悄退化到客户端执行。动手之前，先想清楚：这是内存操作，还是数据库查询？