Expression.Compile()在高频调用下性能差，EF Core中应避免Client evaluation；ParameterExpression须复用同一实例；Compile()非必需，仅在脱离IQueryable且需复用委托时缓存一次。
直接用 Expression.Compile() 构建动态查询条件，在高频调用场景下会显著拖慢性能——它每次执行都触发 JIT 编译，比硬编码 Where(x => x.Status == "A") 慢 10 倍以上。真正要用好表达式树，关键不是“怎么拼出来”，而是“怎么不编译”“怎么不崩”“怎么不被 EF Core 吃掉”。
EF Core 查询中 Expression 不生效？先看日志有没有 Client evaluation
把自定义方法（比如 MyUtil.IsAdult(x)）塞进表达式树，EF Core 默认不认识，整段逻辑会被静默跳过，甚至退化为客户端求值：先查出全部数据，再在内存里过滤。这不是 bug，是设计行为。
- 打开 EF Core 日志，搜索关键字
Client evaluation；只要出现，就说明表达式没被翻译成 SQL - EF Core 只翻译内置函数（如
string.Contains、DateTime.Now）和显式注册的 DbFunction（通过ModelBuilder.HasDbFunction()） - 简单条件优先用
Expression.Equal、Expression.AndAlso、Expression.Call（仅限已知可翻译的静态方法），绕开任意封装方法调用
多个条件组合时 ParameterExpression 必须是同一个实例
用 Expression.Invoke() 或手动拼 AndAlso 组合多个子表达式时，如果每个子表达式都新建自己的 ParameterExpression，哪怕名字、类型完全一样，运行时也会抛 ArgumentException: The parameter 'x' was not bound in the expression。
- 错误写法：
var p1 = Expression.Parameter(typeof(User), "u"); var p2 = Expression.Parameter(typeof(User), "u");——p1 != p2，绑定失败 - 正确做法：统一声明
var param = Expression.Parameter(typeof(User), "u");，后续所有Expression.Property(param, "Name")、Expression.Equal(...)都复用它 - 如果条件来自不同模块，别传“表达式字符串”或“参数名”，直接传
param实例 +Expression子树
Compile() 不是必须的，多数时候根本不需要调用
EF Core、Dapper（配合表达式解析器）、LINQ to Objects 等场景，你传给 Where() 的本就是 Expression，框架自己会遍历树、翻译或执行。调用 Compile() 反而让 EF Core 失去服务端翻译能力，强制走内存过滤。
- 只在需要反复执行「同一结构」的委托且脱离 IQueryable 场景时才缓存编译结果，例如：通用校验器、规则引擎中的固定策略
- 缓存方式：用
static readonly Func，确保只编译一次_cachedFilter = BuildExpr().Compile(); - 绝对避免在循环里写
expr.Compile()()——等于每轮都 JIT + 执行，CPU 白烧 - 拼接 SQL 字符串？那更不需要
Compile()；表达式树此时只是构造中间逻辑的类型安全 DSL
最常被忽略的一点：表达式树是不可变的。你想“修改”一个已存在的树（比如往已有条件里加一个 AndAlso），实际是创建新树。别试图复用旧节点改属性，要用 ExpressionVisitor 或手动重建——否则看似成功，运行时报错或逻辑错位。
