★ FEATURED ARTICLE 最近整理 C#.Net 底层相关的学习笔记翻到了表达式目录树Expression Tree这一块。别被这个名字吓住表达式目录树说白了就是把一段代码当成数据来看。lambda 写出来后要么被编译成委托直接执行要么被保存成一棵可以被遍历、重构、再执行的树。这棵树里面每一个节点都对应代码里的一个操作参数节点、常量节点、二元运算节点一层套一层。这篇文章适合谁正在学 LINQ 但好奇 IQueryable 为什么能翻译成 SQL 的开发者准备做动态查询拼接、通用映射、反射替代方案的人以及所有被“表达式树不可直接修改”折腾过的人。我会从基本认知讲到手动构建、动态改写再到实际项目和常见问题尽量把实操中容易踩的坑一次说清楚。1. 表达式目录树的基本认知树状结构到底长什么样1.1 从一次简单的加法说起委托与表达式的分岔路口先看两行几乎一模一样的代码Funcint, int, int add (a, b) a b; ExpressionFuncint, int, int addExpr (a, b) a b;第一行把 lambda 编译成了一个委托运行它就是在执行加法动作。第二行则完全不同C# 编译器看到目标类型是ExpressionTDelegate就不会生成执行代码而是生成一棵描述这段代码结构的树。addExpr不会帮你算加法而是告诉你“这里有两个参数 a 和 b要做一个加法操作”。这就是表达式目录树最核心的价值代码本身变成了可检查、可分析、可动态修改的数据结构。你可以把它理解成一份菜谱而不是一盘做好的菜。菜谱可以被人读、被人改甚至被翻译成另一种语言的菜谱最终要不要照着做由你决定。我们可以直接把树的内部结构拆出来看var body addExpr.Body as BinaryExpression; Console.WriteLine(body.NodeType); // Add Console.WriteLine(body.Left); // a Console.WriteLine(body.Right); // b Console.WriteLine(addExpr.Parameters[0].Name); // a Console.WriteLine(addExpr.Parameters[1].Name); // baddExpr.Body是表达式的主体主体是BinaryExpression因为a b是一个二元操作。NodeType是操作类型Left和Right分别指向左操作数和右操作数。Parameters则保存了 lambda 的参数列表。这里有个很容易混淆的概念ExpressionFuncint, int, int本身也是一个表达式而且它的 NodeType 是Lambda所以它通常被叫做“Lambda 表达式”。真正干活的是它的 Body 和 Parameters。你可以随时通过Compile()把这棵树变回委托Funcint, int, int addFunc addExpr.Compile(); Console.WriteLine(addFunc(3, 5)); // 8所以表达式目录树是“可逆”的从代码到树再从树到代码。大部分时候我们关注的是中间那一段树的状态。1.2 表达式的家谱核心节点类型速查刚开始接触表达式树的人最痛苦的就是看到满屏的Expression.xxx。其实常用的节点类型有限记住下面这张表基本就能应付大多数场景。节点类型对应的代码结构常见例子LambdaExpressionlambda 表达式x x 1ParameterExpression参数占位符lambda 里的xConstantExpression常量1、abc、nullBinaryExpression二元运算a b、a b、a bUnaryExpression一元运算/转换!flag、(int)x、x is stringMethodCallExpression方法调用str.Contains(a)MemberExpression成员访问obj.Name、order.AmountNewExpression构造函数调用new Person()ConditionalExpression条件表达式a ? b : c每种节点都可以通过Expression静态方法直接创建比如Expression.Parameter创建参数节点Expression.Add创建加法节点。ExpressionType枚举里有上百种具体操作类型但大多数都是在这几类节点的基础上的细分。还有一个值得知道的事情是C# 编译器把 lambda 转换成表达式树时并不会支持所有 C# 语法。比如await、lock、foreach这类语句形态不能直接出现在表达式树里。虽然你可以通过手工构建Expression.Assign等方式拼出类似逻辑但那已经是另一层级的操作了不是编译器直接提供的。理解这一点能帮你避开把普通 lambda 和表达式树强行对等的误区。2. 从零构建与解析表达式目录树2.1 手动拼装不用 lambda 也能造出表达式日常开发中很多表达式树来自编译器对 lambda 的转换。但动态场景下你可能连一个写死的 lambda 都没有只知道“有两个参数要做加法类型是 int”这时候就要手动构造。手动构造的套路非常固定ParameterExpression paramA Expression.Parameter(typeof(int), a); ParameterExpression paramB Expression.Parameter(typeof(int), b); BinaryExpression addBody Expression.Add(paramA, paramB); ExpressionFuncint, int, int addExpr Expression.LambdaFuncint, int, int(addBody, paramA, paramB); Funcint, int, int addFunc addExpr.Compile(); Console.WriteLine(addFunc(3, 5)); // 8Expression.Parameter是在声明一个“待定输入”它并不持有具体值只是一个符号。Expression.Lambda的作用是把主体和参数列表组装成一个完整的 lambda 表达式参数列表的顺序就是委托参数从左到右的顺序。为什么强调顺序因为同一个BinaryExpression节点如果参数顺序反了生成的委托签名也会反。曾经见过有人手工拼 SQL WHERE 条件表达式时参数顺序写错了查询结果完全对不上排查半天才发现是构造 lambda 时把参数列表放反了。更常见的操作是创建常量节点。比如把数字 18 变成表达式树里的常量ConstantExpression ageConst Expression.Constant(18, typeof(int));注意指定类型typeof(int)是个好习惯尤其是当你传入null时Expression.Constant(null)会创建一个类型为object的常量节点后续和其它节点组合时经常出类型不匹配的问题。2.2 反向拆解如何阅读一棵已有的表达式树如果说手动构建是“从零拼装”那反向拆解就是“读树”。读树的方法很简单从根节点出发递归遍历子节点。我经常在调试时写一个这样的辅助方法static void PrintExpression(Expression node, int depth 0) { string indent new string( , depth * 2); Console.WriteLine(${indent}{node.NodeType}: {node}); switch (node) { case LambdaExpression lambda: foreach (ParameterExpression p in lambda.Parameters) { Console.WriteLine(${indent} Param: {p.Name} ({p.Type.Name})); } PrintExpression(lambda.Body, depth 1); break; case BinaryExpression binary: PrintExpression(binary.Left, depth 1); PrintExpression(binary.Right, depth 1); break; case UnaryExpression unary: PrintExpression(unary.Operand, depth 1); break; case MethodCallExpression call: if (call.Object ! null) { PrintExpression(call.Object, depth 1); } foreach (Expression arg in call.Arguments) { PrintExpression(arg, depth 1); } break; case MemberExpression member: if (member.Expression ! null) { PrintExpression(member.Expression, depth 1); } break; } }打印出来的结果大概是这样Lambda: p (p.Age 18) Param: p (Person) GreaterThan: (p.Age 18) MemberAccess: p.Age Parameter: p Constant: 18这种方式比直接看ToString()更利于调试因为你不仅能看到节点的值还能看到节点类型。更重要的是你可以在访问每个节点时插入断点观察具体进入的分支。很多“为什么表达式翻译不了”的问题最终都靠这种递归遍历找到了原因。3. 表达式树的动态改写与查询拼接实战3.1 表达式树是不可变的用 Visitor 完成“改写”表达式树最大的特点之一也是最大的坑它不可变。你不能直接把某个节点的Left改成另一个节点。BinaryExpression.Left只有 getter没有 setter。那动态需求怎么办比如我有一个官方默认条件p p.Age 18现在因为业务调整把所有默认的 18 换成 25。不能改原树就新建一棵树。ExpressionVisitor就是为此设计的它会把整棵树遍历一遍并返回一棵新树。public 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 (Equals(node.Value, _oldValue)) { return Expression.Constant(_newValue, node.Type); } return base.VisitConstant(node); } }用法ExpressionFuncPerson, bool predicate p p.Age 18; Expression rewritten new ReplaceConstantVisitor(18, 25).Visit(predicate); ExpressionFuncPerson, bool newPredicate (ExpressionFuncPerson, bool)rewritten;注意返回的是Expression通常需要转回具体的 lambda 类型。Visit返回新树原predicate对象保持不变。为什么不能直接改因为表达式树的节点内部是一大堆只读字段。这种不可变性是刻意设计好处是安全你可以放心缓存和共享同一棵表达式树不用担心被别的代码破坏。代价就是所有“修改”都要通过 Visitor 模式。3.2 多条件查询拼接And/Or 扩展方法实现动态查询最常见的需求是用户在前端勾了几个筛选条件后端要把这些条件拼接成一个完整的查询表达式。比如“库存大于 0”和“价格小于 50”合并成“库存大于 0 并且价格小于 50”。两个 lambda 直接写left right不能编译因为left和right是ExpressionFuncT,bool对象而不是 bool。常见解法是写一个扩展方法把两个表达式合并成一个新的表达式树。核心难点在于参数统一。p p.Stock 0里的p和q q.Price 50里的q虽然看起来都是参数但在表达式树层面是两个完全不同的ParameterExpression对象。必须先把两边 Body 里的参数都替换成同一个新参数。public static class PredicateBuilder { public static ExpressionFuncT, bool AndT( this ExpressionFuncT, bool left, ExpressionFuncT, bool right) { ParameterExpression param Expression.Parameter(typeof(T), x); Expression leftBody new ReplaceParameterVisitor(left.Parameters[0], param) .Visit(left.Body); Expression rightBody new ReplaceParameterVisitor(right.Parameters[0], param) .Visit(right.Body); Expression body Expression.AndAlso(leftBody, rightBody); return Expression.LambdaFuncT, bool(body, param); } } public class ReplaceParameterVisitor : ExpressionVisitor { private readonly ParameterExpression _oldParam; private readonly ParameterExpression _newParam; public ReplaceParameterVisitor(ParameterExpression oldParam, ParameterExpression newParam) { _oldParam oldParam; _newParam newParam; } protected override Expression VisitParameter(ParameterExpression node) { return node _oldParam ? _newParam : base.VisitParameter(node); } }使用方式很简单ExpressionFuncProduct, bool inStock p p.Stock 0; ExpressionFuncProduct, bool cheap p p.Price 50; ExpressionFuncProduct, bool combined inStock.And(cheap); var result localProducts.Where(combined.Compile());我强烈建议在本地内存集合测试时用Compile()转成委托但如果localProducts是IQueryableProduct直接传combined就行让查询提供程序自己去翻译。合并时用Expression.AndAlso而不是Expression.And前者对应 C# 的有短路语义后者对应位运算在布尔筛选里语义有差别。这个方法虽然短但非常实用。我前面提到的参数替换问题其实就是很多人拼接表达式失败的根本原因。如果你不在拼装前统一参数最后生成的 lambda 里会出现两个不同的参数节点行为会非常诡异。3.3 动态排序与字段投影的另一个入口动态排序也很常见。前端传一个字符串Price后端就要按商品价格排序。用反射当然能拿到属性但更好的做法是构造表达式树ParameterExpression param Expression.Parameter(typeof(Product), p); MemberExpression prop Expression.Property(param, Price); ExpressionFuncProduct, decimal orderLambda Expression.LambdaFuncProduct, decimal(prop, param); IQueryableProduct query products.AsQueryable(); query query.OrderBy(orderLambda);这个写法最关键的是属性类型要匹配。如果Price是decimallambda 类型就要写FuncProduct, decimal。一旦属性类型不固定有些人会图省事写成Expression.LambdaFuncProduct, object(...)也就是把属性值 Convert 成object。内存里没毛病但如果交给某些查询提供程序翻译就可能遇到无法翻译的转换节点。所以能用强类型委托就不要随便装箱成object。动态投影、字段选择也是同样的套路。你只需要把Expression.Property换成Expression.New或Expression.MemberInit就可以构造出new { ... }之类的匿名对象。当然动态投影比动态排序更麻烦因为匿名类型本身需要动态定义表达式树的优势这时候就体现出来了。4. 表达式树在项目中的典型应用场景4.1 让 LINQ 查询真正落地的翻译管道很多初学者理解不了为什么同一个Where方法在IEnumerableT和IQueryableT上的行为不一样。关键差别就在参数类型Enumerable.Where(this IEnumerableT, FuncT, bool) Queryable.Where(this IQueryableT, ExpressionFuncT, bool)前者接收的是一个已经执行就绪的委托后者接收的是一棵还未执行的表达式树。ORM 这类查询提供程序拿到表达式树后会遍历树里的节点把它翻译成目标数据库能理解的查询语言。比如p p.Price 50 p.Stock 0翻译后大约是 SQL 里的WHERE Price 50 AND Stock 0。这就是为什么数据库查询无法把任意 C# 方法调用都翻译过去。如果表达式树里出现了一个MethodCallExpression而 SQL 里并没有对应物就很可能会在运行时抛出“无法翻译”的异常。理解了树的结构你排查这类报错时就不会一头雾水。还有一点要注意有时候你改用FuncT,bool重载查询看似正常但一部分条件被拉到了内存里过滤数据量大时性能会崩。检查一下自己写的是Func还是Expression往往能避免一个隐藏的性能炸弹。4.2 替代反射的高性能属性访问器反射的GetValue/SetValue写起来方便但每次调用都要经过方法查找、参数包装、类型转换等一系列开销。用表达式目录树可以生成强类型委托把反射的性能损失降到最低。一个简单的属性读取器public static class PropertyAccessorT { public static FuncT, object BuildGetter(string propertyName) { ParameterExpression obj Expression.Parameter(typeof(T), obj); MemberExpression prop Expression.Property(obj, propertyName); UnaryExpression convert Expression.Convert(prop, typeof(object)); return Expression.LambdaFuncT, object(convert, obj).Compile(); } }再看属性写入器public static ActionT, object BuildSetter(string propertyName) { ParameterExpression obj Expression.Parameter(typeof(T), obj); ParameterExpression value Expression.Parameter(typeof(object), value); MemberExpression prop Expression.Property(obj, propertyName); UnaryExpression convertedValue Expression.Convert(value, prop.Type); BinaryExpression assign Expression.Assign(prop, convertedValue); return Expression.LambdaActionT, object(assign, obj, value).Compile(); }使用var getName PropertyAccessorPerson.BuildGetter(Name); var name getName(person);第一次构建表达式树时会慢一点但编译成委托之后后续调用开销和直接调用差不多。如果你的程序需要大量读取某个对象的属性比如对象映射、数据导入导出这种优化非常值得。注意不要每次调用都BuildGetter那等于每次都把表达式树重新编译一遍比反射还慢。正确的做法是构建一次并缓存后面反复使用同一个委托。4.3 轻量级业务规则与校验引擎表达式树也能用来做简单的规则引擎。把规则定义成一组ExpressionFuncT, bool然后依次评估或动态组合。var rules new ListExpressionFuncOrder, bool { o o.Amount 0, o o.CustomerLevel 1, o o.Status ! OrderStatus.Closed }; bool CheckOrder(Order order) { return rules.All(rule rule.Compile()(order)); }代码里注意一个问题rules.All每次都会对rule调用Compile()。如果规则列表固定最好在规则注册时就把编译好的委托缓存下来不要每次校验都编译。规则引擎的优势是规则本身可以作为配置项存在甚至可以由另一个系统传入表达式字符串本地动态构建表达式树后执行。比起到处硬编码 if-else这种方案更灵活。不过我不建议把表达式树当成万能银弹。规则数量少、变化频率低时老老实实写判断代码反而更好读、好维护。表达式树真正的价值在于“规则本身要被动态管理”或者“规则要被翻译到其他执行环境”的时候。5. 高频问题与性能排查记录5.1 为什么一执行 Compile 就变慢缓存策略Compile()不是免费的。表达式树编译会把树结构转化为一个可执行委托这个过程有解释、类型检查、IL 生成或类似的开销。某些复杂表达式树第一次编译可能要花几十甚至上百毫秒所以绝对不要在高频调用路径上反复 Compile。比较好的做法是静态缓存private static readonly ConcurrentDictionarystring, FuncPerson, object GetterCache new ConcurrentDictionarystring, FuncPerson, object(); public static FuncPerson, object GetGetter(string propertyName) { return GetterCache.GetOrAdd( propertyName, name PropertyAccessorPerson.BuildGetter(name)); }除了缓存编译后的委托也可以考虑缓存表达式树本身。特别是查询条件这种高度复用的树结构重复拼接和重复编译都是浪费。绑定参数值即可最终整棵树的形状是稳定的。5.2 二元运算符常见异常类型不匹配与提升规则手动构建表达式时最常碰到的一个异常就是InvalidOperationException: The binary operator Add is not defined for ...。看下面这个例子Expression left Expression.Constant(1); Expression right Expression.Constant(2L); // 下面这行会抛出异常 Expression bad Expression.Add(left, right);因为左边是int右边是longC# 编译器里1 2L是合法的会自动提升为long运算。但手工构建表达式树时不会自动做这种隐式转换需要你自己补一个Convert节点Expression safe Expression.Add( left, Expression.Convert(right, typeof(int)));要理解原因编译器在生成表达式树时会把所有隐式转换都显式记录为UnaryExpression节点。手工搭建时这一步必须靠人手完成。另一个容易踩的点是可空类型。比如p p.Age null它的 Body 不是一个简单的ConstantExpression比较而是带可空语义的 BinaryExpression。如果要动态构建类似条件建议先打印出编译器生成的那棵树照着结构去拼而不是凭感觉拍脑袋。5.3 闭包变量引发的“不可翻译”问题变量捕获是个很容易误解的点。看这段代码int minAge 18; ExpressionFuncPerson, bool predicate p p.Age minAge;minAge是局部变量但在表达式树里它并不是一个死板的值副本。C# 编译器会生成一个闭包对象然后在树里通过MemberExpression访问闭包对象的字段。如果你在表达式构造之后修改minAge闭包字段的值也会变化所以树最终执行时用的是最新值。但在动态构造表达式树时如果你自己写Expression.Constant(minAge)那就是在构造那个瞬间把值固定死。之后再改minAge不会影响已经构造好的表达式。这个差异常常让人困惑。更麻烦的是某些涉及闭包的复杂表达式在查询提供程序眼中可能无法翻译。比如在Where(p IsQualified(p) p.Age minAge)中调用了自定义函数IsQualified这个MethodCallExpression在数据库查询翻译阶段很可能直接被判死刑。排查思路不是去硬背规则而是把表达式树打出来看它到底有哪些节点、哪些节点不该出现。5.4 调试与查看表达式树的实用技巧我最后再分享一个自己常用的调试习惯遇到“查询无法翻译”或者拼接结果错误时第一件事就是打印表达式树的ToString()。Console.WriteLine(predicate.ToString());ToString()会输出接近 C# 语法的简化字符串比如p (p.Age 18)适合快速肉眼判断。如果ToString()看起来没毛病再用前面 2.2 节的递归打印方法把节点类型一层层展开你会立刻看到哪一层多了一个Convert哪一层参数对不上哪一层把AndAlso写成了位运算。调试器里也可以直接展开表达式对象看属性。Body、NodeType、Parameters这些字段在复杂的拼接场景下比看报错信息有用得多。我曾经排查过一个动态排序出错的案例表面上只是字段名拼写错误但真正的问题出在Expression.Property生成的是MemberExpression参数类型却是另一个父类对象的参数导致表达式树里出现了一个“参数不属于当前 lambda”的隐藏节点这种问题光看报错文本真的很难定位。根据个人经验表达式树是那种“知道了原理就很简单不知道原理处处碰壁”的知识点。我不建议死记硬背所有节点类型但强烈建议自己在项目里写几个小工具方法一个递归打印表达式树一个统一替换参数一个缓存编译委托。把这几个工具备好以后遇到动态查询、动态映射、动态排序基本都能从容应对。表达式树本身没有太多新东西难的是在真正需要时想到用它以及知道它会在底层怎样“变形”。
阅读完成 · 觉得有帮助？
