Where 返回待执行的查询描述，需调用 ToList() 等触发执行；多条件宜拆解为命名方法；EF Core 中慎用 Contains、导航属性和非纯函数；注意 null 安全与类型擦除。
Where 是最常用也最容易出错的 LINQ 过滤方法——它不执行、不报错、不改原集合，只返回一个“待执行的查询描述”，你看到空结果，大概率是忘了触发执行或条件写崩了。
Where 基本用法：必须调用 ToList() 或 foreach 才真正执行
Where 返回的是 IEnumerable<t></t>，不是新集合，只是“怎么查”的计划书。不迭代它，什么都不会发生。
- 错误写法：
var result = users.Where(u => u.Age > 18);—— 此时result还没查，Count()都可能抛异常（如果源是 EF Core 查询且含不可翻译表达式） - 正确做法：显式触发执行，比如
.ToList()、.ToArray()、.FirstOrDefault()，或直接foreach - EF Core 场景下更需谨慎：若
Where后接了.ToString()或GetType()这类无法翻译的调用，会直接报InvalidOperationException: The LINQ expression could not be translated
Where 多条件组合：别堆在一行 lambda 里
复杂判断硬塞进 u => u.Name != null && u.Age >= 18 && u.Status == "Active" && u.CreatedAt > DateTime.Today.AddDays(-7)，可读性差，调试困难，也容易漏空值检查。
- 推荐拆解为命名变量或私有方法：
bool IsEligible(User u) => u?.Name != null && u.Age >= 18;，再传入Where(IsEligible) - 字符串匹配慎用
.Contains("x")：EF Core 翻译成LIKE '%x%'，全表扫描风险高；能用.StartsWith("x")就别用Contains - 避免在 lambda 中调用非纯函数：比如
x => x.UpdatedAt > DateTime.Now每次执行都不同，EF Core 可能缓存错误计划；应提前算好值：var now = DateTime.UtcNow;，再写x => x.UpdatedAt > now
Where 与导航属性联用：EF Core 下极易性能爆炸
写 context.Orders.Where(o => o.Customer.Name == "Alice") 看似自然，但 EF Core 默认会生成隐式 JOIN，若 Customer 表巨大或未建索引，查询可能秒变 10 秒+。
- 先确认是否真需要关联数据：如果只要订单 ID 和客户名，考虑用
Select投影，而不是整个Order实体 - 检查生成的 SQL：用
.ToQueryString()（EF Core 7+）打印实际发出的语句，看有没有意外 JOIN 或 N+1 - 若必须过滤，优先在数据库侧加索引：
CREATE INDEX IX_Orders_CustomerId ON Orders(CustomerId)，再确保Customer表的Name字段有索引
Where 的两个隐藏陷阱：null 安全和类型擦除
Where 不会帮你处理 null，也不会保留原始集合的泛型约束信息——这两点在重构或泛型方法中特别容易翻车。
- 对可能为 null 的引用类型字段做比较前，必须手动判空：
users.Where(u => u.Address?.City == "Beijing")，否则u.Address为 null 时整个表达式返回 false，而非跳过 - 若源是
IEnumerable<object></object>，用Where(x => x is string)得到的仍是IEnumerable<object></object>，不是IEnumerable<string></string>；要转型得接OfType<string>()</string>或Cast<string>()</string>（后者失败抛异常） - EF Core 中，
Where条件里用as或强制转换（如(int?)x.Value）可能无法翻译，换成Convert.ToInt32(x.Value)或数据库函数等效写法
真正难的不是写对 Where，而是预判它在哪一步失效：是在客户端默默过滤？在数据库侧生成了慢 SQL？还是因为类型擦除导致后续操作编译不过？每次加 Where，多问一句“这行代码最终在哪执行、代价是什么”。
