这一篇是表达式目录树系列的第4篇。前几篇聊了表达式树的基础结构、常见节点和基本遍历今天来聊一个让我当初卡了很久的问题C#泛型约束里只能写where T : new()它只认无参构造函数可真实业务里带参数的构造函数到处都是。想写一个通用的泛型工厂既要类型安全又要创建带参数的实例直接撞在语言约束的墙上。后来发现表达式目录树正好能填这个坑而且性能比反射好得多。如果你也封装过IoC容器、对象映射器、配置实体加载之类的东西八成遇到过这种“泛型约束表达不了、反射又太慢”的尴尬。这篇就直接把它拆开从矛盾的本质讲到完整实现再附上我踩过的坑和性能实测结果。1. 泛型约束与带参构造函数的“死结”在哪1.1where T : new()到底限制了什么C#的泛型约束里new()是一个非常容易让人误解的约束。它的字面意思很直白类型参数 T 必须有一个 public 的、无参数的构造函数。但问题是它只能表达“无参可构造”完全没有“带参可构造”这种约束的语法。public static T CreateT() where T : new() { return new T(); }这段代码能编译、能跑但只适用于无参构造。一旦某个类型的构造函数需要传参比如一个订单类必须传入订单号才能创建这个泛型方法就直接歇菜了。你说我能不能约束 T 必须继承某个基类或实现某个接口然后通过接口里的方法去创建实例当然可以但那等于把构造逻辑硬塞到接口里业务代码会变得很别扭而且很多第三方类型根本不会实现你定义的接口。有人会说那我用Activator.CreateInstance不行吗这个方法确实能创建带参数的实例但它绕过了编译期约束把参数塞进一个object[]数组里本质上是在和运行时反射打交道。这就是矛盾的第一个痛点。1.2 反射方案为什么只能救急Activator.CreateInstance(Type type, object[] args)是很多人第一反应能想到的解法。它确实写出了“通用创建带参实例”的效果object obj Activator.CreateInstance(typeof(Order), new object[] { SO-2024-001, 128m });问题在于它慢了不止一个量级。每次调用都要在运行时查找构造函数、做参数匹配、执行反射调用这个开销在一两万次调用的场景下可能感受不明显但放到一个日请求量很大的Web服务或者批量数据处理管道里分分钟变成性能瓶颈。我见过一个同事在大批量导入任务里用Activator.CreateInstance创建上百万个对象那一段跑了将近十秒后来换成表达式树编译委托之后耗时直接降到一秒以内。更麻烦的是Activator.CreateInstance返回的是object你拿回来还得自己做强转而且编译器完全不管参数数量、参数类型对不对所有问题都在运行期爆发。一旦某个构造函数的签名发生了变更你只能靠运行时异常去发现问题。1.3 表达式树的切入点表达式目录树恰好能同时解决“带参数”和“性能”这两个问题。核心思路并不复杂构造函数在.NET里对应一个ConstructorInfo而Expression.New可以把一次构造函数调用描述成一棵表达式树把参数声明成表达式节点把“new 表达式”作为函数体最后用LambdaExpression.Compile()编译成一个强类型委托。编译后的委托本质上就是一段可以直接执行的代码它不再走反射查找那条路调用开销和普通代码几乎一样。换句话说我们用“运行时动态构造一个构造函数调用”代替了“每次运行都去反射创建对象”。这个过程只发生一次之后的每次调用都只是一次普通的委托调用。表达式树在这里扮演的不是黑魔法而是一个“编译器助手”它把无法用泛型约束表达的东西延后到了运行时去构造又不像反射那样每次都付出查找代价。2. 用表达式树设计一个“通用版参数化工厂”2.1 核心思路把构造函数编译成委托上面的场景里真正需要解决的问题是在运行时才知道类型 T 和它的构造函数签名但希望之后每次创建实例都像直接new一样快。表达式树方案的设计目标就是建立一条“构造函数到委托”的转化管线。管线分成三段拿到类型 T 的构造函数信息也就是代码里的ConstructorInfo。把构造函数的每个参数映射成一个表达式节点用Expression.New把它们“拼”成一次构造调用。用Expression.Lambda将整棵树包成一个委托签名Compile()成可执行委托并缓存。这里一个容易被忽略的点是Expression.New在表达式树里并不是真的执行构造函数它只是描述“我要调用这个构造函数”。真正执行要等到Compile()之后。所以整个设计里最贵的一次操作是Compile()但它只发生一次之后就一劳永逸了。2.2 参数数组方案object[] 与 Convert 的配合怎么让一个通用工厂适配任意构造函数最直接的思路是把参数统一塞进一个object[]数组工厂方法的签名写成T Create(params object[] args)。这样做的好处是方法签名固定无论构造函数有几个参数、参数类型是什么都能适配。但问题来了表达式树里Expression.New要求传入的参数表达式类型必须和构造函数形参类型匹配。你把一个类型为object的数组元素表达式直接传给构造函数形参类型对不上编译表达式树时会报参数匹配异常。解决办法是在每个参数表达式上套一层Expression.Convert把object转换为对应的形参类型。这个转换在运行时会对值类型执行拆箱操作对引用类型执行类型转换。也正是因为每次调用都要拆箱、装箱object[]方案在性能上略逊于强类型委托但它换来了极高的通用性。2.3 强类型变体FuncTArg1, TArg2, TResult如果不想承受拆箱和装箱的开销或者希望调用方在编译期就获得参数类型检查还可以做一个强类型版本。思路是让泛型参数个数固定显式声明参数类型public static class TypedFactoryTArg1, TArg2, T { private static readonly FuncTArg1, TArg2, T Creator; static TypedFactory() { ConstructorInfo ctor typeof(T).GetConstructor( new[] { typeof(TArg1), typeof(TArg2) }); if (ctor null) { throw new InvalidOperationException( $类型 {typeof(T).Name} 上找不到 ({typeof(TArg1).Name}, {typeof(TArg2).Name}) 构造函数); } ParameterExpression p1 Expression.Parameter(typeof(TArg1), p1); ParameterExpression p2 Expression.Parameter(typeof(TArg2), p2); NewExpression body Expression.New(ctor, p1, p2); var lambda Expression.LambdaFuncTArg1, TArg2, T(body, p1, p2); Creator lambda.Compile(); } public static T Create(TArg1 a1, TArg2 a2) { return Creator(a1, a2); } }调用方式变成了TypedFactoryint, string, Order.Create(1024, SO-2024-001)编译器就能帮你检查参数数量和类型。代价是你得为每种参数个数单独定义一个泛型类三个参数写一版四个参数再写一版代码比较冗余。从实际角度讲object[]版本适合“你也不知道具体签名是什么”的场景比如IoC容器按注册信息解析组件强类型版本适合调用方明确知道参数形态的场合。两种方案可以共存先用object[]版做一个通用底座在热点路径上再提供强类型入口。3. 从零到一的完整实现3.1 第一步安全地拿到构造函数信息第一步是获取类型 T 的构造函数。直接用typeof(T).GetConstructors()只能拿到 public 构造函数如果目标构造函数是 internal 或者 private还需要指定BindingFlags.NonPublic | BindingFlags.Instance。不过我不推荐默认这样做反射私有构造函数本身就是一种对封装边界的破坏除非你明确知道自己在做什么。在实际开发里一个类型往往有多个构造函数工厂应该选哪一个这没有一个普适答案。我在自定义工具里通常默认选择“参数最多的那个 public 构造函数”因为这对应依赖注入场景中“尽可能注入全部依赖”的直觉如果你有特定的选择策略把这个策略做成一个委托参数暴露给外部比写死在工厂类里更好后面调整起来不用改工厂代码。下面是获取构造函数的那段代码我加上了参数最多的筛选逻辑ConstructorInfo[] ctors typeof(T).GetConstructors( BindingFlags.Instance | BindingFlags.Public); ConstructorInfo selected ctors .OrderByDescending(c c.GetParameters().Length) .FirstOrDefault(); if (selected null) { throw new InvalidOperationException($类型 {typeof(T).Name} 没有可访问的实例构造函数); } ParameterInfo[] ps selected.GetParameters();注意如果你准备把这个工厂类用在泛型容器里选构造函数这个动作应该尽量只做一次并把结果缓存而不是每次创建实例都重新扫一遍构造函数列表。3.2 第二步构造参数表达式并拼接 NewExpression拿到ConstructorInfo和参数列表ParameterInfo[]之后下面这一步是整个方案的核心。我用一个object[]类型的参数表达式作为整个委托的唯一入参然后对每个构造参数都去数组里取对应位置的值。这里有个细节值得单独说如果构造函数的参数类型恰好是object套一层Expression.Convert反而可能是多余的虽然多数情况下也不会报错但为了避免无谓的表达式节点我会在加转换之前先判断一下类型是否一致。逻辑如下面的代码所示。ParameterExpression args Expression.Parameter(typeof(object[]), args); Expression[] argumentExpressions new Expression[ps.Length]; for (int i 0; i ps.Length; i) { Expression arrayItem Expression.ArrayIndex(args, Expression.Constant(i)); if (ps[i].ParameterType ! typeof(object)) { argumentExpressions[i] Expression.Convert(arrayItem, ps[i].ParameterType); } else { argumentExpressions[i] arrayItem; } } NewExpression body Expression.New(selected, argumentExpressions);Expression.ArrayIndex负责从参数数组里取出第 i 个元素它的返回类型是object。Expression.Convert负责把它转换为构造函数所要求的形参类型。如果是值类型最终编译出来的 IL 就是一次unbox.any如果是引用类型就是一次castclass。还需要特别留意的是Expression.New会自动匹配构造函数的参数个数和顺序。你提供几个参数表达式它就会按顺序去找构造函数签名。如果参数表达式的个数、顺序、类型和ConstructorInfo所声明的参数不一致编译时就会抛出异常。所以前面构造argumentExpressions时千万别打乱ParameterInfo[]的顺序。3.3 第三步编译委托并缓存表达式树建好之后用Expression.Lambda把它包装成Funcobject[], T类型的委托。这里指定的委托签名决定了后续调用方看到的工厂方法形态。ExpressionFuncobject[], T expr Expression.LambdaFuncobject[], T(body, args); Creator expr.Compile();这里的Creator是一个静态只读字段private static readonly Funcobject[], T Creator;因为我把编译逻辑放进了泛型类的静态构造函数里而静态构造函数是线程安全的CLR 保证它在第一次访问该类型成员之前恰好执行一次所以不需要加锁也不用写双重检查直接靠静态初始化机制把委托缓存起来即可。要注意的是缓存的是编译后的委托而不是ConstructorInfo本身。这个差别很关键委托相当于把构造函数调用固化成了可直接执行的代码路径后续创建实例时不会再碰反射。3.4 完整代码与调用方式把上面这几步拼起来完整工厂类长这样public static class ParameterizedFactoryT { private static readonly int ArgCount; private static readonly Funcobject[], T Creator; static ParameterizedFactory() { ConstructorInfo[] ctors typeof(T).GetConstructors( BindingFlags.Instance | BindingFlags.Public); ConstructorInfo selected ctors .OrderByDescending(c c.GetParameters().Length) .FirstOrDefault(); if (selected null) { throw new InvalidOperationException( $类型 {typeof(T).Name} 没有可访问的实例构造函数); } ParameterInfo[] ps selected.GetParameters(); ArgCount ps.Length; ParameterExpression args Expression.Parameter(typeof(object[]), args); Expression[] argumentExpressions new Expression[ps.Length]; for (int i 0; i ps.Length; i) { Expression arrayItem Expression.ArrayIndex(args, Expression.Constant(i)); if (ps[i].ParameterType ! typeof(object)) { argumentExpressions[i] Expression.Convert(arrayItem, ps[i].ParameterType); } else { argumentExpressions[i] arrayItem; } } NewExpression body Expression.New(selected, argumentExpressions); ExpressionFuncobject[], T expr Expression.LambdaFuncobject[], T(body, args); Creator expr.Compile(); } public static T Create(params object[] args) { if (args null) { throw new ArgumentNullException(nameof(args)); } if (args.Length ! ArgCount) { throw new ArgumentException( $构造函数要求 {ArgCount} 个参数实际传入 {args.Length} 个, nameof(args)); } return Creator(args); } }调用时非常直观Order order ParameterizedFactoryOrder.Create(SO-2024-001, 128m);Order 的构造函数是Order(string orderNo, decimal amount)这个调用会先触发静态构造函数完成表达式树编译之后再调用就只是执行一个委托。对第一次调用来说静态构造的编译时间是不可忽略的但它只产生一次对后续的千万次调用来说这就是纯赚的收益。3.5 应用现场对象映射与轻量级容器这个通用工厂我第一次真正用起来是在一个轻量级依赖注入容器里。容器注册组件时只提供了Type创建实例需要按最长构造函数动态解析依赖。以前的写法是每次解析都做一次反射构造函数查找后来统一改成表达式树工厂把“构造”这件事变成了纯粹的委托调用解析耗时明显下降代码也直观了很多。另一个常用的地方是DTO映射。比如从数据库实体映射到带参构造的视图模型时视图模型通常有public ViewModel(int id, string name, decimal score)这样的构造函数。过去要么在映射代码里一行行地new ViewModel(...)要么反射创建前者重复代码多后者性能差。用表达式树工厂做一个统一的映射辅助函数参数从源对象里抽取出来然后直接调用编译器级的构造委托代码既紧凑又保持了可读性。如果你连属性初始化也想做表达式树还支持Expression.MemberInit也就是把“构造函数 属性赋值”一并编译进同一个委托。这一步可以作为后续扩展效果和效率都很好。4. 实操中容易踩的坑4.1 参数顺序不对称导致编译失败Expression.New(ConstructorInfo ctor, params Expression[] arguments)对参数顺序非常敏感。假设构造函数签名是Order(string orderNo, decimal amount)你写表达式树时如果把第二个参数当成了第一个Expression.New在构造阶段通常不会立刻报错等到Compile()的时候它会发现这里塞给orderNo的表达式类型是decimal与形参不兼容于是抛出一个ArgumentException或类似异常。排查这个报错有个技巧先看好ParameterInfo[]的实际顺序再对照你构造argumentExpressions的索引一一核对。不要凭记忆去排参数尤其当构造函数有八九个参数的时候顺序错一个都跑不起来。4.2 值类型参数传 null 的奇怪报错Expression.Convert在值类型参数上的行为很微妙。比如构造函数有一个int类型的参数而你在调用Create时传给object[]里的对应位置恰巧是个null。表面上没有提示运行时一执行委托就会在unbox.any那个步骤抛NullReferenceException而且报错位置根本不指向你的源码指向的是表达式树编译生成的内部代码。我第一次遇到时被这个报错误导了很久以为工厂类本身有 bug。后来才意识到是调用方传入了非法数据。解决方式有两个方向一是在Create入口做参数校验对值类型参数逐一检查是否为 null二是在文档或注释里明确约定“值类型参数不得传 null”。我一般两者都做毕竟异常信息越早暴露越好。4.3 构造函数存在但代码里拿不到typeof(T).GetConstructors()默认只返回 public 构造函数。如果你的目标类型把构造函数声明成了 internal外部程序集拿不到工厂就会抛出“没有可访问的构造函数”。这个坑在重构时特别容易出现原来构造函数是 public后来改成 internal 或者加了访问修饰符编译期不报错运行期工厂突然就罢工了。另外一个容易被忽略的场景是构造函数参数本身不符合预期。强类型版本的GetConstructor(Type[])要求参数类型“精确匹配”接口参数和实现类参数在反射里是两个不同的类型。调用方以为传一个接口泛型就行但构造函数给的是具体类结果就是返回 null工厂初始化失败。遇到这类问题先打日志把typeof(T).FullName和尝试匹配的签名打出来排查速度会快很多。4.4 缓存失效与误用 Activator 的后果既然用了静态构造函数缓存委托就要小心一种情况静态构造函数里抛异常比如找不到构造函数、参数类型不匹配类型初始化就会失败。之后程序里每次调用ParameterizedFactoryT.Create都会抛TypeInitializationException而不是原来的InvalidOperationException。这意味着问题会被包装一层排查时要通过InnerException才能看到真正原因。也有人在工厂缓存逻辑里加了双重锁实际上完全没有必要。静态构造函数由 CLR 保证线程安全加锁只是增加复杂度。真正需要小心的反倒是那些想省事直接混用Activator.CreateInstance的做法两者混用并不会出错但一旦走了 Activator前面费劲建立的高性能路径就形同虚设了整条慢代码还是慢。要保持统一要么全走表达式树要么全走反射。5. 性能实测与适用场景判断5.1 用 Stopwatch 实测三种方式为了让你看清差距我做一个很直观的对比。定义一个简单的Order类构造函数有两个参数一个string一个decimal。然后分别用三种方式循环创建 1000 万次for (int i 0; i N; i) { _ new Order(SO- i, 128m); } for (int i 0; i N; i) { _ ParameterizedFactoryOrder.Create(SO- i, 128m); } for (int i 0; i N; i) { _ Activator.CreateInstance(typeof(Order), new object[] { SO- i, 128m }); }直接new Order(...)是测试的基准线ParameterizedFactoryOrder.Create走的是表达式树编译出来的委托Activator.CreateInstance则是每次走完整反射查找。5.2 测试结果怎么看在我的本机环境下常见的 x64 运行时三次结果大致呈一个阶梯状创建方式1000万次耗时相对直接 new 的倍数直接调用构造函数约 0.4 秒1x表达式树编译委托约 0.8 秒约 2 倍Activator.CreateInstance约 8 秒以上约 20 倍以上这里有个重要前提上面测试里表达式树用的是object[]参数版本每次调用都要分配参数数组还有装箱拆箱所以比直接new慢了大约一倍。这个差距不是表达式树调用本身造成的而是object[]封装的固有开销。如果你改用强类型委托版本差距会显著缩小接近直接构造的水平。再看 Activator它的慢是“每次调用都慢”倍率随着构造参数越多越明显。数量级上它比表达式树慢 10 到 20 倍是一个很常见的实测结果。5.3 什么情况下别用表达式树表达式树不是万能的有些场景我反而建议别用。如果你的目标是“写一个最简单的东西快速跑通”且创建实例的次数还不到几次那直接用Activator.CreateInstance完全没问题表达式树的前期编译成本反而是一种过度设计。另一个不建议用的场景是极频繁的小对象创建每次参数类型完全不同、签名频繁变化。表达式树工厂虽然能编译新签名但编译本身有开销如果每次都要编译新类型整体性能会非常差。这种情况下更适合老老实实写普通构造函数调用或者调整设计让对象的构造函数收敛成少数几个固定形态。还有一类特殊情况要提一下如果你需要创建的对象根本不是通过构造函数实例化的比如某些框架允许用FormatterServices.GetUninitializedObject跳过构造函数那表达式树方案就别硬套了。表达式树解决的核心矛盾始终是“我能知道构造签名但泛型表达不了”不是“我想绕过构造函数”。收个尾说点个人体会做通用的创建逻辑时最忌讳的就是一上来就反射。反射写起来是一行的事但性能债会不知不觉变成架构债。表达式树方案真正解决的是一个“编译期到运行期的桥梁”问题泛型在编译期给不了你带参构造函数的能力那就到运行期用表达式树把调用逻辑构建出来再编译回一个强类型委托让后续调用回归高速通道。我个人在实际项目中通常会把ParameterizedFactoryT作为通用底座在确定存在热点的路径上再补一个强类型工厂类或直接手写构造调用。最后多提一句表达式树构造出的委托可以直接放进一个并发字典里按类型缓存这样你的应用里无论经过多少条不同的创建路径同一类型都只需要编译第一次。能把这一整套玩明白后面再做对象映射、依赖注入、动态代理这些偏底层的框架逻辑都会顺手很多。