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

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

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

OrderByThenBy 的链式调用顺序不能反

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

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

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

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

所有 LINQ 查询操作符(WhereOrderByGroupBy)返回的都是 IQueryableIEnumerable,它们仅仅是一个“查询定义”,并不会立刻执行。真正开始干活,是在你开始遍历(比如 foreach),或者调用强制执行方法的时候。

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

本文转载于:https://www.php.cn/faq/2344628.html 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。