先说一个我印象挺深的场景。当时做一个内部管理系统，前端传过一个排序字段名，后端要根据这个字符串动态排序。我一开始写了一大堆switch判断字段，后来觉得不行，改用反射拿属性。能跑，但代码看着别扭，性能也不理想。后来接触了 C# 的表达式树，我才意识到这类"代码即数据"的需求，就该用它来解决。
表达式树是 C# 里把代码当作数据来处理的高级特性，它能把一段 Lambda 表达式拆成一棵结构清晰的树：谁是参数、谁是常量、谁是运算、谁是方法调用，一目了然。你可以检查这棵树，可以重写它，也可以把它编译成可执行的委托。这篇文章就把我自己在用表达式树过程中总结的用法、场景和踩过的坑完整写出来，希望能给正需要它的人节省点时间。
1. 表达式树到底解决了什么问题
1.1 从"黑盒委托"到"白盒代码"
很多人写了多年 C#，每天在用 Lambda，但没认真想过一个问题：普通委托（Func<T>、Action<T>）一旦编译成 IL，对你来说就是一个黑盒。你只知道"调用它，能得到结果"，但你没法在运行时问它一句："你内部是怎么算出来的？"。
表达式树把这个黑盒打开了。你用Expression<Func<int, bool>>声明的代码，不会被立刻编译成 IL，而是被构造成一棵内存中的树状数据结构。这棵树上的每个节点都是一个对象，比如ParameterExpression表示参数，ConstantExpression表示常量，BinaryExpression表示加法、大于等二元运算。程序可以像看图纸一样查看这段代码的内部结构。
我用一个生活化一点的类比来解释：普通委托就像一本已经印刷好、装订成册的成品书，你只能翻开、阅读，没法知道作者当时是怎么构思的；表达式树则是这本书的写作大纲、段落草稿和素材清单，你能看到每一句话是怎么搭出来的，甚至可以直接改掉其中一段再重新装订出版。这个"代码可审查、可修改"的能力，是表达式树区别于普通委托最根本的地方。
1.2 "代码当作数据"到底意味着什么
把代码当作数据，听起来抽象，落到实际开发里就是三个具体能力：审查、改写、转译。
审查，是指可以在运行时不执行代码、直接分析代码结构。比如你拿到一个表达式x => x.Age > 18 && x.Score >= 60，你可以遍历这棵树，问它：你这个条件判断里用到了哪些属性？是不是有属性访问比较？有没有危险的调用？这些在运行时都能知道。
改写，是指可以对这棵树进行修改后，再编译成新的委托。比如我写过一个工具，把所有"大于等于"的操作统一改成"大于 59"的写法，用ExpressionVisitor遍历一遍节点替换一下，最后Compile()出来就是全新的函数。注意这里不是把字符串替换，而是真的把内存里的对象节点换掉，逻辑严密。
转译，是指把表达式树翻译成另一种语言或另一种结构。最典型的就是 LINQ to Entities 和 LINQ to SQL，EF Core 拿到表达式树之后，翻译成 SQL 字符串再发给数据库执行。你写的Where(u => u.Age > 18)并不是在内存里过滤数据，而是被翻译成了WHERE [u].[Age] > 18。这就是"代码即数据"最强大的落地场景。
打个比方：导航软件不是直接把你送到目的地，而是先根据起点和终点规划出一条路线，这条路线就是一份"数据"。你可以在这份数据上检查是否经过拥堵路段，也可以修改路线绕开某个路口，最后再按这条路线开车。表达式树就是这段"路线数据"，委托才是"正在开的车"。
1.3 表达式树和反射的边界
很多人容易把表达式树和反射混在一起，因为两者都能在运行时操作类型和成员。但它们的能力边界非常清晰：反射看到的是"类型结构"，比如类有哪些属性、方法、特性；表达式树看到的是"代码逻辑"，比如这段代码怎么比较、怎么调用、怎么构造对象。反射另一个重要能力是动态调用，但动态调用通常只是拿到MethodInfo后Invoke，而表达式树可以直接创建一段全新的逻辑并编译成委托，这是反射做不到的。
举个直观的例子。你想调用某个对象的私有方法，反射可以做到：拿MethodInfo，再Invoke。但你想在运行时动态生成一个x => x.A * x.B + x.C这样的函数，反射是做不到的，表达式树可以。更极端一点，你想根据外部配置生成一段新的业务规则，比如"当金额大于某值时走审核流程"，表达式树可以用Expression类从零搭建出来，然后编译执行。
另一个实际感受：反射在调用编译后的代码时，开销通常比直接调用高一个量级，尤其涉及值类型装拆箱时更明显。表达式树虽然在构建时也有开销，但Compile()一次之后，后续调用就是纯委托调用，性能接近手写代码。所以高频路径上，能用表达式树替代反射的地方，我都会尽量替换。
2. 表达式树的核心解剖：关键节点与构造方式
2.1 常见的表达式节点类型
表达式树由各种节点组成，入门阶段你最常接触的是下面这些节点类型。
| 节点类型 | 作用 | 典型用法 |
|---|---|---|
ParameterExpression | 表示参数，比如x =>中的x | Expression.Parameter(typeof(int), "x") |
ConstantExpression | 表示常量，比如x > 5中的5 | Expression.Constant(5) |
BinaryExpression | 表示二元运算，比如加减乘除、比较、逻辑与或 | Expression.Add、Expression.GreaterThan、Expression.AndAlso |
MethodCallExpression | 表示方法调用，比如s.Contains("a") | Expression.Call(instance, methodInfo, args) |
MemberExpression | 表示属性或字段访问，比如u.Age | Expression.Property(param, "Age") |
NewExpression | 表示构造函数调用，常用于匿名对象拼接 | Expression.New(constructorInfo) |
ConditionalExpression | 表示条件表达式，即三元运算符 | Expression.Condition(test, ifTrue, ifFalse) |
记住这些节点的关键点是：一棵表达式树一定有一个根节点，通常是LambdaExpression（它的子类型是Expression<TDelegate>）。根节点往下，内部节点是各种非叶子表达式，叶子节点一般是ParameterExpression、ConstantExpression。你可以把整棵树想象成一张家谱，每个节点都知道自己的父亲是谁——Parent属性不直接暴露，但通过Visit遍历时能感知到层级关系。
2.2 从零构造一棵表达式树
先看最简单的手工构造流程。假设你想构造出x => x > 5，用表达式树 API 写出来是这样：
// 1. 定义参数 x var x = Expression.Parameter(typeof(int), "x"); // 2. 定义常量 5 var five = Expression.Constant(5); // 3. 创建 x > 5 var greaterThan = Expression.GreaterThan(x, five); // 4. 换成 Lambda 表达式树 var expr = Expression.Lambda<Func<int, bool>>(greaterThan, x); // 5. 编译成委托 var func = expr.Compile(); Console.WriteLine(func(7)); // True Console.WriteLine(func(3)); // False这个流程本身不难，难的是理解每一步的意义。Expression.Parameter创建的是"形式参数"，它不是具体的值，而是一个占位符。Expression.GreaterThan会生成一个BinaryExpression，它的两个子节点分别指向刚才的x和five。Expression.Lambda<TDelegate>把一棵表达式挂到某个委托签名上，最后Compile()将其转换为真正的委托代码。
值得提醒的是，很多人在构造时容易漏掉Expression.Convert。比如属性类型是int，而你需要的委托签名是Func<T, object>，直接拿Expression.Property的结果去拼Lambda会报类型不匹配。解决办法就是套一层Expression.Convert(property, typeof(object))，把值转成object再塞进委托。这在动态排序里尤其常见，一会儿我会写到。
2.3 拆开看一棵表达式树的内部结构
我习惯在调试时把表达式树的形状打印出来。写一个递归方法很简单：
static void PrintTree(Expression node, int depth = 0) { var indent = new string(' ', depth * 2); Console.WriteLine($"{indent}{node.NodeType}: {node}"); switch (node) { case BinaryExpression binary: PrintTree(binary.Left, depth + 1); PrintTree(binary.Right, depth + 1); break; case LambdaExpression lambda: PrintTree(lambda.Body, depth + 1); break; case MethodCallExpression call: if (call.Object != null) PrintTree(call.Object, depth + 1); foreach (var arg in call.Arguments) PrintTree(arg, depth + 1); break; } }拿Expression<Func<int, int>> expr = x => x * 2 + 3;来打印，输出大致是：
Lambda: x => ((x * 2) + 3) Add Multiply Parameter: x Constant: 2 Constant: 3注意这里加法的左右顺序：x * 2是左子节点，3是右子节点。如果你打印一个x => 3 + x * 2，树的形状会不一样，但最终求值结果一样。这告诉我们：表达式树的形状忠实地反映了代码的语法结构，括号和优先级已经在树里固化了，不需要像解析字符串那样手动处理优先级。
3. 动手写一个表达式树"小引擎"
3.1 动态排序器：让字符串字段名变成真代码
回到开头那个动态排序需求。我要实现的是：输入一个属性名字符串，输出一个可以直接传给OrderBy/OrderByDescending的表达式树。核心方法长这样：
public static Expression<Func<T, object>> BuildSortExpression<T>(string propertyName) { var param = Expression.Parameter(typeof(T), "x"); var property = Expression.Property(param, propertyName); var converted = Expression.Convert(property, typeof(object)); return Expression.Lambda<Func<T, object>>(converted, param); }调用端这样用：
var query = users.AsQueryable(); var sortExpr = BuildSortExpression<User>("Age"); query = query.OrderByDescending(sortExpr);这里的两个关键点是：Expression.Property接收的字符串必须是类型上真实存在的公共属性名，否则会在运行时抛出ArgumentException，而不是编译期报错；Expression.Convert是为了把属性值装箱成object，这样才能统一塞进Func<T, object>签名里。如果属性本身是string这种引用类型，Convert也不是不能省，但为了代码通用，我这里统一都加了。
性能上，这个方法每次都重新构建表达式树，高频排序时肯定不行。优化方案是加缓存，以(typeof(T), propertyName)作为 key 缓存编译结果。我在后面会单独讲缓存策略，这里先记住结论：构建一次、缓存、重复使用，就能把动态排序性能拉到和手写 Lambda 几乎无差别的水平。
3.2 查询条件拼接：把可变参数变成查询表达式
做后台系统的时候，最常遇到的需求是动态拼接查询条件。前端传进来一堆筛选条件，后端要根据这些条件过滤数据，条件数量、字段名都是不确定的。每写一个分支去判断有没有这个条件，代码就会膨胀得很难看。
我用表达式树的方式做一个通用的条件构造器，思路是：把每个条件转成一个小表达式，然后通过Expression.AndAlso（即 C# 中的&&）拼接起来，最后用一个统一的ParameterExpression替换所有表达式里的参数。
public static Expression<Func<T, bool>> CombineFilters<T>( IEnumerable<Expression<Func<T, bool>>> predicates) { var param = Expression.Parameter(typeof(T), "x"); Expression? body = null; foreach (var predicate in predicates) { // 把原表达式的参数替换成统一的 param var replaced = new ParameterReplaceVisitor(predicate.Parameters[0], param) .Visit(predicate.Body); body = body == null ? replaced : Expression.AndAlso(body, replaced); } if (body == null) return x => true; return Expression.Lambda<Func<T, bool>>(body, param); }其中替换参数的核心依赖ExpressionVisitor的一个子类：
class ParameterReplaceVisitor : ExpressionVisitor { private readonly ParameterExpression _oldParam; private readonly ParameterExpression _newParam; public ParameterReplaceVisitor(ParameterExpression oldParam, ParameterExpression newParam) { _oldParam = oldParam; _newParam = newParam; } protected override Expression VisitParameter(ParameterExpression node) { return node == _oldParam ? _newParam : base.VisitParameter(node); } }为什么要做参数替换？因为多个Expression<Func<T, bool>>可能各自声明了不同的参数名，比如u => u.Age > 18、x => x.Score >= 60。直接拼AndAlso会创建两个独立的参数节点，翻译或编译时会出现"参数来源不一致"的异常。统一替换成同一个ParameterExpression实例，才能保证表达式树的参数引用完全一致。
3.3 用 ExpressionVisitor 重写表达式树
ExpressionVisitor是表达式树里我最常用的类，它是专为重写表达式树设计的基类。你不需要自己去遍历树，只要重写对应节点类型的Visit方法，就能精准地拦截和替换。
我做过一个小规则引擎，要把"大于等于 18 岁"这种条件统一改写成"大于 17 岁"。当然实际场景更复杂，比如把某个函数调用替换成另一个函数，这里演示一下思路：
class RewriteAgeVisitor : ExpressionVisitor { protected override Expression VisitBinary(BinaryExpression node) { // 只拦截成员访问 Age 的二元比较 if (node.NodeType == ExpressionType.GreaterThanOrEqual && node.Left is MemberExpression member && member.Member.Name == "Age") { // 改成 Age > 17 return Expression.GreaterThan( member, Expression.Constant(17, typeof(int))); } return base.VisitBinary(node); } }使用方式：
Expression<Func<User, bool>> expr = u => u.Age >= 18; var rewritten = (Expression<Func<User, bool>>)new RewriteAgeVisitor().Visit(expr);这里有一个容易忽略的细节：Visit返回的是Expression，但原始类型被保留下来了，你要用强转把结果转回Expression<Func<User, bool>>。因为表达式树的不可变性，Visit不会修改原树，而是返回一棵新树。如果你没有任何节点被修改，它返回的也可能是原对象的引用，这点在比较引用时要注意。
4. 实战落地：从脱敏到权限过滤
4.1 字段脱敏：拦截手机号输出
在给第三方提供数据的时候，经常遇到字段脱敏的需求：手机号中间四位要打码，身份证部分隐藏。如果每个接口都写一遍脱敏逻辑，太容易漏。用表达式树可以做一个全局的字段访问拦截器。
思路是在VisitMember里识别属性名，如果是Mobile，就把它替换成一段调用字符串处理方法的表达式：
class MaskingVisitor : ExpressionVisitor { protected override Expression VisitMember(MemberExpression node) { if (node.Member.Name == "Mobile") { // node 表示 u.Mobile，我们要把它替换成 u.Mobile.Substring(0, 3) + "****" + u.Mobile.Substring(7) var replaceMethod = typeof(string).GetMethod("Substring", new[] { typeof(int), typeof(int) }); var start = Expression.Call(node, replaceMethod, Expression.Constant(0), Expression.Constant(3)); var end = Expression.Call(node, replaceMethod, Expression.Constant(7), Expression.Constant(4)); var concat = typeof(string).GetMethod("Concat", new[] { typeof(string), typeof(string), typeof(string) }); return Expression.Call(concat, start, Expression.Constant("****"), end); } return base.VisitMember(node); } }这样只要把项目里返回给外部的实体统一经过一次表达式树脱敏转换，所有Mobile字段都会自动变形成138****1234的格式。不需要改实体定义，也不需要调用方感知，这就是表达式树能实现真正意义上的"横切逻辑"的一个例子。
4.2 动态权限过滤器：给查询加一堵墙
多租户系统里有一个非常痛的难题：不同角色看到的数据范围不同。比如普通用户只能看到自己创建的记录，管理员能看到部门所有记录，超级管理员能看到全公司记录。如果所有查询都手写Where(u => u.TenantId == currentTenantId)很容易漏。
用表达式树做一个权限过滤器，思路和 3.2 类似：在用户原有查询条件前面，动态拼接一个权限条件。比如：
public static Expression<Func<T, bool>> ApplyTenantFilter<T>( Expression<Func<T, bool>> userExpr, int tenantId) { var param = Expression.Parameter(typeof(T), "x"); var tenantProperty = Expression.Property(param, "TenantId"); var tenantCondition = Expression.Equal( tenantProperty, Expression.Constant(tenantId)); var replaced = new ParameterReplaceVisitor(userExpr.Parameters[0], param) .Visit(userExpr.Body); var combined = Expression.AndAlso(tenantCondition, replaced); return Expression.Lambda<Func<T, bool>>(combined, param); }这里我踩过坑：如果直接userExpr.Body和tenantCondition拼，两个表达式各用各的参数节点，EF Core 翻译时大概率报错。要做就必须统一参数。另外，TenantId属性如果不存在，Expression.Property会直接抛异常，所以最好在构建前用typeof(T).GetProperty("TenantId")做一次校验，提前发现问题，别把异常留到数据库查询时。
4.3 性能：表达式树编译不能成为瓶颈
表达式树最容易被诟病的是性能。构造树、Compile()都有开销，尤其Compile()内部要生成动态方法，走的是轻量级代码生成，第一次被调用时可能触发 JIT。但只要你用对了模式，性能完全可控。
经验做法是：把构建好并编译好的委托缓存起来，用静态只读字段存：
private static readonly Expression<Func<Order, bool>> ActiveOrderExpr = o => o.Status == 1 && o.Amount > 0; private static readonly Func<Order, bool> ActiveOrderFunc = ActiveOrderExpr.Compile();访问器方法只调用ActiveOrderFunc，不重复构建表达式树。实测中，这种缓存后的调用开销和直接写死o => o.Status == 1 && o.Amount > 0几乎没有差别，因为 CLR 会把委托调用内联到接近零开销的程度。
真正要避免的是：每次请求进来都Expression.Parameter、Expression.Lambda、Compile一条龙。尤其在 Web 高并发场景，这会导致额外的内存分配和 JIT 压力。记住这个原则：表达式树是"一次构建、多次使用"的中间表示，不要把构建过程放在热路径上。
5. EF Core 为什么离不开表达式树
5.1 查询翻译的基本流程
很多人只知道 EF Core 能把 LINQ 查询翻译成 SQL，但没搞懂凭什么能翻译。核心秘密就在表达式树。
IQueryable<T>对象本身不是一个数据集合，它内部保存了两样东西：一个Expression（对查询的描述）和一个IQueryProvider（执行器）。当你写db.Users.Where(u => u.Age > 18)时，并没有立即执行，而是构造了一棵更大的表达式树，把Where调用和里面的u => u.Age > 18都记录下来。等到你去遍历结果、ToList()、FirstOrDefault()的时候，查询才真正开始执行。
执行阶段，IQueryProvider会对这棵表达式树做翻译：先把它拆成一颗颗节点，再调用数据库特定的 SQL 生成器，把方法调用、属性访问、常量、二元运算映射成 SQL 片段。Where变成WHERE，OrderBy变成ORDER BY，Take(10)变成TOP 10或OFFSET ... FETCH。这个过程本身就是表达式树的"转译"能力在生产环境中的一次大规模实践。
5.2 为什么你的自定义方法不能被翻译
经常能看到这样的提问："我写了Where(u => IsAdult(u.Age))，为什么 EF Core 报错说不能翻译？"。答案是：EF Core 的 SQL 翻译器认识Expression类的各种节点，但它不认识你自定义的方法。IsAdult是一个MethodCallExpression，节点本身没有对应的 SQL 映射，翻译器也不愿意去执行你的 C# 方法，因为那会在数据库端引入不可控逻辑。
一旦碰到无法翻译的节点，EF Core 通常有两种处理方式：一是抛异常，告诉你"不能翻译为 SQL"；二是悄悄把剩余逻辑放到客户端内存里执行，最典型的是AsEnumerable()之后的部分。后一种方式容易引起全表加载，性能隐患极大，我建议只要发现一个查询在Where或OrderBy里用了自定义方法，就尽早想办法改写。
正确的做法是把自定义方法拆解成表达式树能理解的基本操作。IsAdult(u.Age)如果可以写成u.Age >= 18，那就直接写后者；如果逻辑比较复杂，可以用三元运算符或者&&、||组合实现。总之，你想让 EF Core 翻译，就得给它吃"它认识的食物"。
5.3 能翻译和不能翻译的操作速查表
我从实际项目里总结了一张速查表，列出了常见的可翻译和不可翻译操作。
| 可翻译操作 | 说明 |
|---|---|
Where、Select、OrderBy、GroupBy、Join | 标准查询运算符，映射到 SQL 子句 |
Contains、StartsWith、EndsWith | 映射成 LIKE 或 IN |
字符串Length、ToUpper、ToLower、Trim | 常用字符串函数 |
Math类的一部分静态方法 | EF Core 专门做了映射，比如Math.Abs、Math.Ceiling |
可空类型的.HasValue、.Value | 映射为IS NULL判断 |
| 比较运算符、逻辑运算符 | 几乎都能翻译 |
| 不可翻译操作 | 说明 |
| 自定义静态或实例方法 | 无 SQL 映射 |
Random.Next | 无法保证确定性 |
| 访问当前对象的私有字段/实例字段 | 反射字段通常不参与翻译 |
DateTime.Now之外的本地时间计算 | 服务器和数据库时区差异大，建议显式传递值 |
使用时还有个小技巧：如果遇到DateTime.Now参与查询，先把var now = DateTime.Now放到查询外部作为局部变量，然后在表达式里引用这个局部变量，这样可以强制 EF Core 把它当作参数，和 SQL Parameter 绑定，执行计划也能复用。
6. 常见问题与避坑技巧实录
6.1 闭包变量被当成常量的坑
用闭包变量构建表达式树，稍不注意就出现诡异问题。看这段代码：
int minAge = 18; Expression<Func<User, bool>> expr = u => u.Age >= minAge; minAge = 25; var func = expr.Compile(); Console.WriteLine(func(user)); // 这里用的 minAge 是多少？答案是：Compile之后的委托里，minAge已经被固定为 18 了，之后你改成 25 不影响已经编译好的委托。因为表达式树捕获闭包变量时，实际上是把闭包对象作为ConstantExpression的一个实例值嵌入树中，后续修改外部变量其实修改的是闭包对象的字段，但树的节点内容已经定格。
如果你需要表达式树反映外部变量的最新值，就不要把变量直接塞进表达式，而是应该把它当作普通参数传进去：
Expression<Func<int, bool>> expr = (min) => min >= 18; var result = expr.Compile()(minAge);或者保持参数化查询，在 EF Core 场景里，把外部变量转成表达式参数能更好利用 SQL 参数缓存。这个不为多数人所知的细节，我建议你记下来，调试时很省时间。
6.2 调试表达式树的实用工具
表达式树调试起来比普通代码难，因为它不是文本，而是结构化的对象图。我最常使用的调试方式是两种：一是利用ToString()，它会输出一个近似于 C# 源码的字符串，比如u => (u.Age > 18)；二是写一个递归打印方法，像第 2 章那样，一层一层输出NodeType和内容。
比ToString()更好用一点的是DebugView属性。这个属性是 .NET 专门给调试器准备的，设计为只读的调试视图。你可以在调试器快速监视窗口里输入expr.DebugView，它会显示一棵带缩进、很接近源码的树结构，比ToString()输出更精细，连闭包变量的处理都能看到一点点痕迹。注意它是调试专用的，不要在业务代码里依赖它做解析，内部结构随时可能调整。
还有一个我常用的辅助手段：在Test环境里直接把表达式树序列化成可读文本，比如写一个ExpressionDumper工具。由于表达式树本身是对象图，你要避免循环引用导致序列化栈溢出，建议只遍历NodeType、Type和关键子节点，别想着把每个MemberInfo都倒出来，信息太多反而难读。
6.3 高频调用时的 GC 压力与缓存策略
动态构建表达式树意味着会产生大量临时对象：每个ParameterExpression、ConstantExpression、BinaryExpression都是一个对象，频繁创建会带来明显的 GC 压力，尤其在一些每秒调用上千次的服务里。
我的做法分三层：最底层是针对固定逻辑，直接用static readonly字段缓存表达式树和编译好的委托，几乎零开销；中间层按"类型 + 属性名"做字典缓存，比如动态排序表达式，用ConcurrentDictionary<(Type, string), object>存编译结果；最上层是业务层缓存，整个条件组合构建后缓存，只有配置变更时清缓存。
关于字典的 key，最好用(Type, string)这种不可变元组，不要图方便拼字符串 key（"类名.属性名"这种拼法在热路径上会产生字符串分配）。另外，缓存不要无脑长期持有，如果表达式树依赖租户、用户 ID 这类变化频率较高的数据，密钥就要带上这些上下文，或者干脆不缓存只缓存表达式模板，把参数值通过Invoke传入。
6.4 操作可空类型时的装拆箱陷阱
表达式树在拼接可空类型（int?、DateTime?）时也容易踩坑。比如你要构造u => u.Birthday.HasValue && u.Birthday >= threshold，直接对MemberExpression做GreaterThanOrEqual可能会报类型不匹配，因为Birthday类型是DateTime?，不是DateTime。
这时候要先访问.Value属性，或者加一层转换：
var birthday = Expression.Property(param, "Birthday"); var hasValue = Expression.Property(birthday, "HasValue"); var valueExpr = Expression.Property(birthday, "Value"); var threshold = Expression.Constant(DateTime.Today); var compare = Expression.GreaterThanOrEqual(valueExpr, threshold); var combined = Expression.AndAlso(hasValue, compare);另外一个常见问题是拿Expression.Constant(null)去对比可空类型，有时候需要把 null 的Type显式指定为目标类型，否则编译期或运行期可能出现不兼容的异常。这个细节在动态 SQL 调试里很常见，看到异常里带着 "binary operator ... not defined" 之类的话，八成就是这个问题。
最后：说几句闲话
表达式树这个特性，入门时觉得绕，用多了就会发现它是 C# 里非常趁手的一件工具。它最大的价值不是让你炫技，而是能在运行时把"代码逻辑"当成"可操作的数据"来对待，这给了很多框架级设计巨大的灵活性。我实际用下来最省心的场景还是动态排序和动态拼接查询条件，这两类需求本身就很适合表达式树：条件可组合、逻辑可替换、最终还能交给 EF Core 翻译成高效的 SQL。
我个人在表达树上的成长路径是先打印树的形状，熟悉节点类型，然后写自定义ExpressionVisitor改树，最后再去看 EF Core 的 SQL 日志对比验证翻译结果。这个路径对新人来说比较平滑，不会一上来就被各种节点类型吓到。这里再分享一个小技巧：如果你要在项目里大规模使用表达式树，建议先封装一个"表达式构建器"的工具类，把Parameter、Equal、AndAlso这些低级 API 包一层，业务代码里只写语义化方法，团队上手会快很多。
表达式树能演化的方向其实还有很多，比如规则引擎、动态表单校验、接口回放工具，都是拿表达式树当中间表示。但前提是先把今天说的这些基础场景吃透，尤其是参数替换、缓存编译、可空类型处理，这几关过了，后面基本就顺了。
