应优先使用 IQueryable 链式 Where 构建动态查询，因其 100% 可被 EF Core 翻译；仅当字段名或操作符完全动态时，才需手动构建 Expression.Tree，并注意参数复用、类型匹配及 EF Core 兼容细节。
直接用 PredicateBuilder 容易踩坑——它不是 .NET 原生类，依赖第三方库（如 LinqKit），且在 EF Core 6+ 中与异步查询（ToListAsync）配合时可能抛出 NotSupportedException: The LINQ expression could not be translated。真要动态拼条件，优先走原生 IQueryable 链式 Where，再按需补表达式树。
为什么不要一上来就用 PredicateBuilder
PredicateBuilder 的 True<t>()</t> / False<t>()</t> 返回的是 Expression<func bool>></func>，但它的 And / Or 方法返回的仍是表达式，不是可直接拼进 IQueryable.Where() 的委托；若没调用 .Compile()（不推荐）或没启用 LinqKit 的 AsExpandable()，EF 就无法翻译成 SQL，查着查着就本地执行或报错。
- EF Core 默认不支持运行时拼接的复杂表达式树，除非显式启用扩展
-
AsExpandable()会改变查询管道，可能干扰跟踪行为或投影优化 - 同一查询中混用
PredicateBuilder和普通Where容易导致表达式嵌套过深，SQL 生成失败
IQueryable 链式 Where 是最稳的起点
绝大多数多条件场景（非字段名/操作符完全动态）用链式 Where 足够，且 100% 可被 EF Core 翻译。
- 每个
Where调用都会追加一个独立的 SQLAND条件，顺序无关，组合安全 - 参数判空逻辑清晰：
if (!string.IsNullOrEmpty(keyword)) query = query.Where(x => x.Name.Contains(keyword)); - 时间字段别用
null直接比较，改用startTime.HasValue+startTime.Value - 枚举筛选用强类型比较：
if (status != Status.Unknown) query = query.Where(x => x.Status == status);
字段名/操作符真要动态？用 Expression.Tree 手组
当筛选字段由字符串（如用户选“创建时间”“更新人”）或操作符（“大于”“包含”“不等于”）决定时，才需要表达式树。核心是复用 ParameterExpression，避免重复创建参数。
- 先定义统一参数：
var param = Expression.Parameter(typeof(User), "x"); - 用
Expression.Property(param, fieldName)拿属性，别硬写x.CreatedAt - 用
Expression.Constant(value)包装值，注意DateTime?、int?要解包 - 组合多个条件用
Expression.AndAlso(left, right)，最后用Expression.Lambda<func bool>>(body, param)</func>封装 - 传给
query.Where(lambda)前，确保 lambda 类型是Expression<func bool>></func>，不是Func<user bool></user>
容易被忽略的 EF Core 兼容细节
动态查询跑不起来，八成卡在这些地方：
-
Contains在 SQL Server 上默认大小写不敏感，但 PostgreSQL 默认敏感——别依赖它做精确匹配，该用EF.Functions.Like或数据库函数时就用 -
DateTime.MinValue传给数据库可能溢出（SQL Server 最小值是 1753-01-01），改用DateTimeOffset.MinValue或自定义哨兵值 - 对导航属性动态筛选（如
x.OrderItems.Count > 0）必须确认 EF 已正确配置关系映射，否则生成 SQL 报错 - 异步查询末尾必须用
await query.ToListAsync()，不能漏掉await——动态拼的 IQueryable 不会自动异步化
