C#表达式树入门：把代码当作数据，实现动态查询与规则引擎

很多写了两三年 C# 的同学，看到“表达式树”这个概念还是会下意识绕开。一方面觉得它只在框架底层出现，平时写业务用不上；另一方面，网上的教程要么直接贴出一堆Expression<Func<...>>的 API 文档，要么一上来就讲访问者模式，读完之后还是不知道这东西到底能干嘛。其实表达式树没有那么玄，核心就一句话：把代码当作数据。

这句话听起来抽象，但一旦你理解了它，就能做到很多“正常写法做不到”的事：在运行时动态拼查询条件、把 C# 代码翻译成 SQL、让系统根据用户配置自动生成规则、甚至把一段逻辑序列化出来传给另一个服务执行。我最初接触表达式树是因为要做一个动态筛选功能，需求里用户要能自己选字段、选操作符、填值，然后拼出一套查询条件传给后端。用硬编码if写了几十个分支之后，我意识到这条路走不通，才开始认真啃表达式树。这篇文章就按我实际学习和使用的路径来写，尽量把每一步为什么这么做讲清楚，你能直接照着用。

1. 表达式树解决的本质问题：把代码变成看得见、摸得着的数据

1.1 从一段“写死的查询”说起

假设你有一个商品列表，想在内存里筛选出价格大于 100 的商品。最简单的写法人人都熟：

var result = products.Where(p => p.Price > 100).ToList();

这行代码的p => p.Price > 100是一个Lambda 表达式。运行时，C# 编译器有两种处理方式。如果Where接收的参数类型是Func<Product, bool>，那编译器就把这个 Lambda 编译成一个匿名方法，你拿到的是一个可以直接调用的委托。但如果Where接收的参数类型是Expression<Func<Product, bool>>，情况就完全不同了——编译器不会生成可执行的方法，而是把这行代码拆解成一棵数据结构，记录下“参数 p”“访问 p 的 Price 属性”“常量 100”“大于比较”这几件事。

这棵数据结构就是表达式树。你可以在程序运行时遍历它、修改它、给它加条件、甚至把它翻译成别的语言。委托是“已经做好的菜”，表达式树是“菜谱”，还带着每种食材的产地和切法说明。

我第一次理解这个区别的时候，脑子里冒出来的念头是：既然能拿到“菜谱”，那理论上就能在用户面前实时调整菜谱，而不需要重新炒一盘菜。这就是动态查询、动态规则引擎这类需求的最底层依据。

1.2 表达式树在 .NET 中的具体形态

表达式树的根类型是System.Linq.Expressions.Expression，它是一个抽象类，下面派生了几十个具体节点类型。常用的有这么几类：

看到这一长串类型别慌，你日常写代码里用到的语法，表达式树里几乎都有对应的节点。理解了“代码被拆成了什么结构”，后面所有操作就都围绕“怎么组装这些节点”“怎么遍历这些节点”展开。

实际上，.NET 里还有一个更底层的概念叫IL（中间语言），委托本质上就是一段编译好的 IL；表达式树则完全跳过 IL 这一步，直接用对象图描述逻辑。这也是为什么表达式树能被 EF Core 这类 ORM 拿去解析——如果是 IL，想还原成 SQL 就太难了，但对象图遍历起来就轻松得多。

1.3 表达式树和委托的分水岭：什么时候用哪个

我知道很多人会问：既然 Lambda 既能转成委托，又能转成表达式树，那我到底该用哪个？这里面有一个非常实用的判断标准：

如果你只需要在本地执行逻辑，用委托；如果这个逻辑要被“另一个执行者”理解并翻译成其它形式，用表达式树。

举两个极端例子：

• 内存里对List<Product>做筛选，Where(p => p.Price > 100)用委托，线程池直接执行就完了。
• 后端的IQueryable<Product>要生成 SQL 发给数据库，Where(p => p.Price > 100)如果用委托，EF Core 根本没法翻译，因为拿不到“逻辑结构”；必须用表达式树，EF Core 才能遍历出Price > 100然后拼进WHERE子句。

本质上可以这样理解：委托是逻辑的执行形态，表达式树是逻辑的描述形态。描述形态的好处是你可以先“改描述”再“执行”，或者让别人（比如 ORM）去执行。

2. 三种构建表达式树的方式，从省事到硬核

2.1 方式一：让编译器帮你生成

最常见也最省事的方式，就是直接写一个 Lambda 表达式，但显式声明类型为Expression<>：

Expression<Func<Product, bool>> expr = p => p.Price > 100;

这一步由编译器完成所有节点创建。你可以直接查看expr的结构，它本质上是一棵树的根节点。这种方式适合表达式内容是静态写死的场景。比如你要给一个查询封装一个通用的“启用状态”过滤条件：

public static Expression<Func<T, bool>> ActiveFilter<T>(bool active) where T : IHasActive { return t => t.IsActive == active; }

这里active是外部变量，Lambda 表达式捕获它之后，表达式树里会生成一个闭包对象，然后通过字段访问来获取这个变量的值。这里埋了一个坑：如果后续修改了active变量的值，表达式树在解析时取到的不是创建时的值，而是当前值。这个我后面在踩坑章节再展开。

2.2 方式二：用手动拼装的方式构建节点

运行时动态构造表达式时，编译器帮不了你，因为你根本不是在写源码，而是在“组装逻辑”。这时候要用Expression类下面的各种静态工厂方法：

// 手工创建 p => p.Price > 100 ParameterExpression param = Expression.Parameter(typeof(Product), "p"); MemberExpression priceProp = Expression.Property(param, nameof(Product.Price)); ConstantExpression hundred = Expression.Constant(100m); BinaryExpression greaterThan = Expression.GreaterThan(priceProp, hundred); Expression<Func<Product, bool>> expr = Expression.Lambda<Func<Product, bool>>(greaterThan, param);

这段代码做的事情，和编译器帮你做的事情完全一样，只是每一步都摆到了明面上。用工厂方法拼装的最大价值在于：你可以根据运行时的配置来决定要不要拼某个节点。比如用户选择了“价格在 100 到 500 之间”，你就拼一个AndAlso（对应&&）；如果用户只选了“价格大于 100”，你就不拼右半部分。

很多动态查询框架的底层就是这么干的：定义一堆小的表达式片段，然后按用户配置往上叠加。叠加的入口就是Expression.AndAlso/Expression.OrElse。

2.3 方式三：从已有表达式里“拆”和“改”

有些场景下，你手头有一个现成的表达式树，但你想改掉其中一部分。比如系统里有一个基础过滤条件p => p.Price > 100，现在要在另一个模块里变成p => p.Price > 500。你当然可以用工厂方法重新拼一棵树，但更优雅的方案是：遍历原树，找到那个值为 100 的ConstantExpression，替换成Expression.Constant(500m)，然后返回一棵新树。

这种“遍历并替换”的工作，需要用到表达式访问者。自定义一个继承ExpressionVisitor的类，重写对应节点的 Visit 方法：

class ReplaceConstantVisitor : ExpressionVisitor { private readonly object _oldValue; private readonly object _newValue; public ReplaceConstantVisitor(object oldValue, object newValue) { _oldValue = oldValue; _newValue = newValue; } protected override Expression VisitConstant(ConstantExpression node) { if (node.Value?.Equals(_oldValue) == true) return Expression.Constant(_newValue, node.Type); return base.VisitConstant(node); } } // 使用 var newExpr = (Expression<Func<Product, bool>>)new ReplaceConstantVisitor(100m, 500m).Visit(expr);

访问者模式是表达式树世界里最核心的扩展手段。你甚至可以用它做更疯狂的事：把p => p.Name.Contains("手机")翻译成p => p.Name.Contains("手机") || p.Description.Contains("手机")，只要在访问MethodCallExpression节点时，找到string.Contains这个方法，然后把“第二个参数（搜索词）”拎出来，构造一棵OrElse的新树并返回替换原来节点。

这两种方式没有绝对优劣。静态代码场景优先让编译器生成，动态拼装场景优先用工厂方法，做横切改造场景用访问者。我实际项目里的经验是：80% 的代码是用方式一和方式二组合，访问者主要用来做“统一逻辑注入”，比如给所有查询条件自动加上“软删除标记过滤”。

3. IQueryable 和表达式树的化学反应：LINQ 翻译机制

3.1 为什么 LINQ to Objects 和 LINQ to SQL 行为不一样

这是表达式树最重要、也最容易被误解的实际应用场景。同样是Where，List<T>用的是Func<T, bool>，而IQueryable<T>用的是Expression<Func<T, bool>>。这种签名差异不是设计上的任性，而是刻意为之：

• List<T>.Where希望你在本地立刻算出结果，所以直接执行委托。
• IQueryable<T>.Where希望你把查询条件“存起来”，等真正要结果的时候再统一处理。

这就像外卖点餐：List<T>是你直接去后厨说“我要一份辣椒炒肉”，师傅当场就炒；IQueryable<T>是你把菜名写在一张单子上，后厨根据你这一整桌的所有要求（荤素搭配、忌口、加辣）统一安排出餐。

IQueryable内部维护了一个Expression属性，整个过程就是不断往表达式树里“追加”节点。products.Where(p => p.Price > 100).OrderBy(p => p.Name).Take(10)执行时，真正触发工作的是最后的ToList()或者First()这类执行方法。执行方法会调用IQueryProvider.Execute，把整棵表达式树交给 provider 去处理。

3.2 表达式树如何被翻译成 SQL

我拿 EF Core 举例（其它 ORM 原理类似，只是解析器实现不同）。当 EF Core 拿到一棵表达式树，它会做两件事：

第一步，把这棵树的节点拆平，理解成一个逻辑链条：参数p是一个Product实体，p.Price > 100是一个二元比较，p.Name是一个列映射，Take(10)是TOP(10)或者OFFSET FETCH。

第二步，把这个逻辑链条转成 SQL 片段并拼接：

SELECT TOP(10) * FROM Products AS p WHERE p.Price > 100 ORDER BY p.Name

这个翻译过程并不是无脑“把 C# 运算符换成 SQL 运算符”——它对很多细节做了语义映射。比如 C# 里的string.Contains会翻译成 SQL 的LIKE '%值%'；string.StartsWith翻译成LIKE '值%'；DateTime.Year会被翻译成YEAR(列)。这也是为什么你在表达式树里不能随便调用自定义方法：EF Core 的翻译器没见过你的方法，它就报错“无法转换”。

这里有个值得注意的边界：并不是所有 C# 代码都能被翻译成 SQL。比如p => p.Price > GetMinPrice()，GetMinPrice()是本地方法，EF Core 可以先把GetMinPrice()的结果算出来，然后把常量塞进表达式树再翻译；但如果你在一个Where(p => p.CalculateDiscount() > 10)里调用了实体实例方法，EF Core 就无能为力了。实际工作中，这类错误多半在运行期才爆出来，排查起来颇费功夫。写IQueryable链式调用时，心里要有一根弦：这棵树最后是要被“翻译”的，不要把“执行”的思维方式带进来。

4. 访问者模式与动态查询实战：做一个可以“搭积木”的查询器

4.1 访问者模式在表达式树里到底扮演什么角色

如果要处理一棵表达式树，最简单粗暴的方式是递归遍历节点类型，判断if (node is BinaryExpression)再转。但这样写出来，代码和节点类型强耦合，每加一个需求就要改一大坨。ExpressionVisitor提供了一种更干净的遍历框架：它定义了一整套虚空方法，每个节点类型对应一个VisitXxx方法。你只需要重写自己关心的那部分，其它节点交给基类按默认方式处理。

用访问者能做很多实际操作中非常有用的事：

• 参数统一替换：比如把查询里的p => p.Price > 100和q => q.Score > 80里的参数p、q统一替换成某个固定参数，这样两棵表达式树才能用AndAlso合并。
• 条件注入：给一棵没有任何过滤条件的表达式树统一加 “IsDeleted == false” 节点。
• 表达式规范化：把!(a > b)改写成a <= b，减少后续解析的复杂度。
• 日志打印：遍历整棵树，输出一份可读的逻辑结构描述，方便排查和单测断言。

所以我对访问者模式的定位是：表达式树的“手术刀”，你用它做精准改造，而不是每次都要重写整棵树的递归逻辑。

4.2 动态多条件拼装的完整示例

这是我认为最有实战价值的片段。假设某管理后台的列表页允许用户组合筛选：状态（等于/不等于）、价格区间（大于/在区间内）、名称（包含）。页面传来的是一组动态配置对象，系统需要根据配置拼查询。

先定义一个简单的筛选描述：

public class FilterField { public string FieldName { get; set; } // "Price" / "Name" / "Status" public string Operator { get; set; } // "eq" / "neq" / "gt" / "contains" / "between" public object Value { get; set; } public object Value2 { get; set; } // between 的右边界 }

然后写一个拼接器：

public static Expression<Func<T, bool>> BuildFilter<T>(IEnumerable<FilterField> fields) { ParameterExpression param = Expression.Parameter(typeof(T), "x"); Expression? body = null; foreach (var f in fields) { Expression? condition = BuildCondition(param, f); if (condition == null) continue; body = body == null ? condition : Expression.AndAlso(body, condition); } if (body == null) return x => true; return Expression.Lambda<Func<T, bool>>(body, param); } private static Expression? BuildCondition<T>(ParameterExpression param, FilterField f) { MemberExpression member = Expression.Property(param, f.FieldName); switch (f.Operator) { case "eq": return Expression.Equal(member, Expression.Constant(f.Value, member.Type)); case "neq": return Expression.NotEqual(member, Expression.Constant(f.Value, member.Type)); case "gt": return Expression.GreaterThan(member, Expression.Constant(f.Value, member.Type)); case "contains": var contains = typeof(string).GetMethod("Contains", new[] { typeof(string) })!; return Expression.Call(member, contains, Expression.Constant(f.Value?.ToString())); case "between": var greater = Expression.GreaterThanOrEqual(member, Expression.Constant(f.Value, member.Type)); var less = Expression.LessThanOrEqual(member, Expression.Constant(f.Value2, member.Type)); return Expression.AndAlso(greater, less); default: return null; } }

用的时候，你先针对实体构造一个基础表达式，比如默认排除已删除数据：

Expression<Func<Product, bool>> baseFilter = p => p.IsDeleted == false;

再拼上用户条件：

var dynamicFilter = BuildFilter<Product>(userFilters); var combined = Expression.Lambda<Func<Product, bool>>( Expression.AndAlso(baseFilter.Body, dynamicFilter.Body), baseFilter.Parameters[0] );

这里有个非常重要的细节：不能直接baseFilter.Body和dynamicFilter.Body执行AndAlso，因为两棵树的参数p和x不是同一个ParameterExpression实例。必须用baseFilter.Parameters[0]做统一参数，或者先通过访问者把dynamicFilter的参数替换成baseFilter的参数。这个坑我当初踩了整整一个下午，报错信息特别抽象，后来才发现是参数引用不一致。

如果只是内存查询，这一步拼完，直接.Compile()转成委托就能用。但如果你要的是数据库查询，就要把最终拼好的表达式树作为参数传给IQueryable.Where(...)，让 EF Core 去翻译，千万别提前.Compile()——一旦编译成委托，EF Core 就完全看不懂了，只能把整个表拉回内存再筛选，性能直接崩溃。很多同学在生产环境里遇到的“查询奇慢无比”，十有八九就是这个原因。

5. 性能考量、调试技巧与高频踩坑速查

5.1 表达式树的性能开销从哪里来

表达式树本身是对象图，创建它当然比直接调用方法要慢。但慢多少、值不值得，取决于你怎么用。我总结过三层开销：

第一层是构建开销。用 Lambda 语法让编译器生成时，这部分几乎可以忽略；用手动工厂方法拼装，主要耗时在反射调用Expression.Property等 API，单个节点的构建开销在纳秒级别，只要不在热循环里重复构建，问题不大。

第二层是编译开销。把表达式树.Compile()成委托，本质上是一次 JIT 编译，这个开销可能要几十微秒到几毫秒不等，取决于树的大小。如果同一个表达式树需要被反复执行，一定要缓存编译结果，不要每次都Compile()。我见过有人在一个循环里对同一个表达式反复Compile()，循环 10 万次，硬生生把几百毫秒的任务拖成几十秒。

第三层是解析开销。这个在你的代码里看不到，发生在 EF Core 内部。EF Core 收到表达式树后要做翻译和缓存，如果表达式树每次结构都不同（比如动态拼装时节点顺序不一样），EF Core 的查询缓存就会频繁失效，每次都要重新翻译。所以动态拼装查询时，尽量保证节点顺序稳定，或者把拼好的表达式树缓存起来。

针对这三层开销，我给一个明确的建议：如果你有一段逻辑是静态写死的，永远不要为了“用表达式树”而用表达式树；只有逻辑本身需要动态变化时，表达式树才是正确选择。

5.2 调试表达式树的三种实用方法

表达式树在调试器里的默认展示并不友好，你看到的是一个对象图，瞬间就头晕。我常用的调试方法有三个。

方法一：把整棵树转成可读字符串。直接调用expr.ToString()可以得到一个接近 C# 语法的字符串，比如p => (p.Price > 100)。这个方法适合粗看，但成员访问、闭包捕获等情况展示得不够精细。

方法二：用 ExpressionVisitor 打印节点详情。写一个简单的访问者，重写所有VisitXxx方法，按缩进输出节点类型、节点类型、节点值，就能得到一份完整的树形结构输出。这个对理解“表达式到底被拆成了什么”非常有帮助。

class DebugVisitor : ExpressionVisitor { private int _depth; protected override Expression VisitBinary(BinaryExpression node) { Console.WriteLine($"{new string(' ', _depth)}Binary: {node.NodeType}"); _depth++; base.VisitBinary(node); _depth--; return node; } // 按需重写其它 Visit 方法 }

方法三：借助表达式树可视化工具。某些 IDE 或在线工具可以把表达式树渲染成真正的树状图，节点之间的嵌套关系一目了然。如果你手头没有趁手工具，方法二已经足够用。

调试动态拼装的表达式树有一个通用心得：把拼装过程拆开，每拼一个条件就打印一次中间结果。不要等拼了七八个条件之后再统一看，那样出了问题根本定位不到是哪一个环节。我写动态查询器的时候，习惯性地在BuildCondition每个分支返回前加一行日志输出，就是靠这个定位了好几个“参数使用不一致”的问题。

5.3 高频踩坑速查表

这几个坑，基本覆盖了我这些年见到的大部分表达式树问题：

这里面我要重点展开一下“闭包变量被视作常量”的坑。举个具体场景：

int threshold = 100; Expression<Func<Product, bool>> expr = p => p.Price > threshold; threshold = 500; var compiled = expr.Compile(); // 你以为结果是 Price > 100，实际是 Price > 500

为什么？因为编译器生成表达式树时，threshold被封装到一个闭包对象里，表达式树里的MemberExpression访问的是闭包对象的字段，而不是值拷贝。当你改了threshold，闭包对象的字段也跟着变，所以解析时拿到的是 500。这在动态拼装场景里非常容易被忽略——你以为自己在拼装时“已经锁定了当时的值”，其实没有。

提示：表达式树默认的行为是“引用变量”，不是“拷贝值”。想要固化某个值，请显式构造Expression.Constant(threshold)。

再补充一个 EF Core 相关的常见问题。很多人在写查询的时候，会自然而然地写：

var query = db.Products.Where(p => p.Price > GetMinPrice());

如果GetMinPrice()是一个本地静态方法，EF Core 一般会先把它求值为常量再翻译，这没问题。但如果GetMinPrice()里有不可翻译的逻辑，或者访问了某个外部对象实例，EF Core 就可能报错。保险起见，先把值算出来：

var minPrice = GetMinPrice(); var query = db.Products.Where(p => p.Price > minPrice);

这样无论是可读性还是对 EF Core 的友好度，都明显更好。

另外一个我最近才注意到的细节：表达式树的ToString()输出里面，闭包变量显示为“value(...)”，而不是你预期的变量名。如果你在排查问题时发现输出和源码写法对不上，先想想是不是有闭包参与。这个现象本身不一定是 bug，但它提示你：这棵树的结构已经不是“你写的样子”了，它多了一层闭包对象的间接访问。

6. 表达式树的进阶延展：我能拿它做什么

表达式树能做的事远不止动态查询。我梳理几个自己研究过或者看别人做过的方向，给你作为后续探索的路标。

第一个方向是规则引擎。把业务规则存成配置化数据（比如数据库里的一行记录），运行时用表达式树把配置解释成一段可执行的逻辑。比如“当订单金额超过 5000 且用户等级为 VIP 时，自动打 9 折”，这行规则可以用类似dynamic > 5000 && userLevel == "VIP"的节点拼接出来。规则引擎的好处是：改规则不用发版，只要改配置就行。

第二个方向是表达式模板化。把一段表达式做成模板，用访问者往里面填充不同的参数值。比如你定义好p => p.Price > threshold && p.Status == status，运行时把threshold和status替换成具体值，然后交给查询执行。这比字符串替换拼 SQL 安全得多，因为表达式树天然防注入。

第三个方向是跨进程表达式传递。表达式树是纯数据，理论上可以序列化成 JSON 或二进制流，通过网络传给另一个服务，由对方解析后执行。这个方向比较小众，但确实有人在分布式系统中这么玩，比如把校验规则下发给边缘节点执行。

第四个方向是编译优化与 AOT 辅助。老一点的 ORM 用的是反射读取实体属性，性能差；新一点的方案会提前构建“属性的 getter/setter 表达式树”，然后.Compile()成强类型委托，既绕开反射的性能开销，又保持灵活性。我后来看框架源码，发现很多“高性能”库的底层都在用这个套路。

这些方向不需要你一次全掌握，但当你遇到“逻辑要动态生成、要翻译成别的形式、要反复改造”这类需求时，脑子里能想起来：表达式树就是专门干这个的。

我自己在实际项目里的最后一点体会是：表达式树最大的学习成本不在 API，而在于思维方式的转变。刚开始写Expression.AndAlso的时候，总会下意识地想“这个条件是不是已经算出结果了”，但其实表达式树阶段根本没有执行任何逻辑，它只是在描述“如果成立，结果就是 true”。一旦你接受了“描述和执行分离”这个设定，后面的一切都会变得顺理成章。

如果你现在正被动态查询、规则配置、或者某个“运行时才能决定的逻辑”卡住，不妨花一个下午把表达式树的基础节点过一遍，写一个能打印树结构的调试访问者，再试着拼一个三条件的动态过滤器。这个过程做完，你就能把这个曾经觉得“高级且遥远”的特性，真正变成自己工具箱里顺手的那件工具。