标题里的问题我猜很多写C#的人迟早都会遇到泛型约束里确实写不了where T : new(参数)但你业务里又确实需要根据运行时条件去创建带参数的泛型实例。前面几篇我们把表达式树的基础、遍历和拼接聊得比较透这一篇就集中解决这个矛盾。我的思路很简单——既然编译期没法直接在泛型代码里写new T(...)那就用表达式树在运行时把“构造调用”重新拼出来再编译成委托。这样既绕开了泛型约束的限制又比裸用Activator.CreateInstance干净得多。这一篇的目标读者是那些正在写对象映射、依赖注入容器、ORM实体工厂或者任何需要“反射式创建对象但不想被反射拖累性能”的人。读完你应该能自己写出一个带缓存、可处理多种构造函数参数的泛型实例工厂。1. 先理清矛盾泛型约束与带参构造函数为什么水火不容1.1 泛型约束的那点尴尬C# 的泛型约束里最常见的实例化写法是public T CreateT() where T : new() { return new T(); }这个new()约束的意思是类型 T 必须有一个公开的、无参数的构造函数。它在编译期给了你一个极简的强类型保证但也仅此而已。问题在于真实业务里的实体类很多并没有无参构造函数它们的构造函数形如public class Customer { public Customer(string name, decimal creditLimit) { ... } }如果你试着写where T : new()然后调用new T(张三, 5000m)编译器会直接拒绝。C# 的泛型约束体系里根本没有“带参数构造函数”这个维度的约束没有where T : new(string, decimal)未来也大概率不会有。这不是编译器不想做而是一旦允许这种约束泛型类型擦除和重载解析会变得异常复杂C# 团队选择只保留最保守的无参约束。于是我们就站在了一个很别扭的位置泛型代码想要创建对象只能访问无参构造函数可实际对象往往需要带参构造才能建立有效状态。很多团队的妥协方案是把无参构造函数补上再通过属性赋值初始化状态。这在简单场景下能跑但有些对象一旦创建出来就必须处于有效状态比如数据库实体、配置项、领域模型补无参构造函数和可变属性会破坏封装性甚至会引入额外的 bug 源。1.2 为什么偏偏用表达式树来解最常见的替代方案是反射object obj Activator.CreateInstance(typeof(T), args);这能工作但它有两个让人不舒服的地方。第一Activator.CreateInstance内部走的是完整的反射通道不管构造函数本身多简单调用前都要做参数校验、权限检查、异常包装。第二返回值是object调用方拿到手之后还得自己强转。在高频场景下比如一次性映射十万行数据反射带来的开销会被放大得非常明显。表达式树则给了我们一条折中的路。它的本质是“把一段代码表示成数据结构”然后可以在运行时编译成真实委托。这意味着我们可以用Expression.New去描述一个构造函数调用把外部传入的object[]参数一个个“接”进构造参数里再编译成一个类似Funcobject[], T的委托。编译完成之后后续每次调用本质上就是一次普通委托调用不再需要反射查找构造函数也不再需要Invoke那套包装。用生活类比来解释反射像是你每次去餐厅都现场打电话问菜单、问做法然后让后厨临时开火表达式树则是你头一次去的时候把菜谱抄走之后直接下指令“按这张单子做”。第一次有成本后面次次都快。所以在我看来表达式树解决这个矛盾的两大核心价值就是第一让泛型代码可以在不知道具体类型的情况下动态选择并调用带参构造函数第二把这种动态行为从“每次反射”优化成“一次编译多次使用”。接下来的篇幅我会围绕这两点展开。2. 表达式树解决矛盾的核心思路把构造函数调用当成表达式2.1 Expression.New 与构造函数的选择要从表达式树里构造一个对象最核心的节点是Expression.New。它有两个常用重载一个是直接传Type让表达式树自己去找无参构造函数另一个是传ConstructorInfo加一组参数表达式适合带参构造。在我们的场景里构造函数是动态选出来的所以典型写法是ConstructorInfo ctor typeof(T).GetConstructors() .OrderBy(c c.GetParameters().Length) .FirstOrDefault(); Expression[] arguments ...; NewExpression newExpr Expression.New(ctor, arguments);这是整个方案的支点。拿到NewExpression以后它和普通表达式节点没有本质区别可以被包进LambdaExpression再通过Compile()变成可执行委托。构造函数的选择非常关键。同一个类型有可能存在多个构造函数我们不能只随便拿一个。在我的代码里一个比较稳妥的策略是先看外部传入的object[] args的长度再反过来匹配构造函数参数个数如果多个构造函数参数个数相同再进一步判断各参数类型的兼容性。这个过程放在首次构建表达式树时做之后缓存编译结果后续调用就不需要再做任何匹配。2.2 从“外部参数数组”到“构造函数参数表达式”的桥接这里有个细节很容易被忽略。object[] args是运行时才有的数据而Expression.New需要的是静态参数表达式。怎么把动态数组元素送进构造函数答案是数组索引与类型转换组合起来。比如构造函数第一个参数是string name外部args[0]是一个object。那么我可以构造这样的表达式Expression.Convert( Expression.ArrayIndex(argsExpression, Expression.Constant(0)), typeof(string) )这里argsExpression是指向整个object[]的参数表达式。只要args[0]实际装箱的是一个字符串运行时转换就不会有问题如果传错了类型得到的会是异常而不是编译错误这是动态实例化必须接受的代价。如果构造参数是值类型还需要额外考虑空值保护。因为表达式树里没有 C# 编译器帮忙做“可空判断 默认值”的语法糖你需要自己拼接一个条件表达式Expression.Condition( Expression.Equal(argFromArray, Expression.Constant(null, typeof(object))), Expression.Default(intType), Expression.Convert(argFromArray, intType) )这样当初如果传了null进来值类型参数会落到默认值0而不是抛异常。当然这个策略是否合理取决于业务如果你希望传null到值类型参数时报错那就去掉这个默认值保护。整个桥接过程完成后把所有这些参数表达式放进Expression.New再包成Expression.LambdaFuncobject[], T编译一次存进静态字段问题就解决了。核心代码量不多但每一步都值得写清楚否则调试时很容易被各种奇葩异常折磨。3. 一个可直接套用的泛型实例工厂代码与关键细节3.1 第一版按参数数量匹配构造函数话不多说直接给一个可以直接跑起来的版本。下面的代码会把构造函数匹配和表达式树构造统一封装在一个泛型静态类里public static class GenericFactoryT where T : class { private static readonly Funcobject?[], T _creator; static GenericFactory() { ConstructorInfo? ctor typeof(T) .GetConstructors(BindingFlags.Instance | BindingFlags.Public) .FirstOrDefault(); if (ctor is null) throw new InvalidOperationException(${typeof(T).FullName} 不存在公共实例构造函数。); ParameterExpression args Expression.Parameter(typeof(object?[]), args); ParameterInfo[] parameters ctor.GetParameters(); Expression[] argumentExpressions new Expression[parameters.Length]; for (int i 0; i parameters.Length; i) { Type parameterType parameters[i].ParameterType; Expression arrayItem Expression.ArrayIndex(args, Expression.Constant(i)); if (parameterType.IsValueType Nullable.GetUnderlyingType(parameterType) is null) { argumentExpressions[i] Expression.Condition( Expression.Equal(arrayItem, Expression.Constant(null, typeof(object))), Expression.Default(parameterType), Expression.Convert(arrayItem, parameterType)); } else { argumentExpressions[i] Expression.Convert(arrayItem, parameterType); } } NewExpression newExpr Expression.New(ctor, argumentExpressions); _creator Expression.LambdaFuncobject?[], T(newExpr, args).Compile(); } public static T Create(params object?[] args) { if (args.Length ! typeof(T) .GetConstructors(BindingFlags.Instance | BindingFlags.Public) .First() .GetParameters() .Length) { throw new ArgumentException(参数数量不匹配。, nameof(args)); } return _creator(args); } }这段代码故意做了简化目的是先把主线讲清楚。构造时我们取了第一个公共构造函数如果类型里只有带参构造也无所谓因为GetConstructors()返回的就是所有公共实例构造函数第一个通常能满足演示需求。但真实项目里这样写不够稳我建议至少按参数数量匹配。3.2 参数绑定与类型转换的坑上面循环里有一个容易被忽略的关键点Expression.Convert并不只是做“强转”它会在运行时生成对应的 IL 指令。引用类型之间的转换会变成castclass值类型的装箱对象转换会变成unbox.any这两种指令在语义上已经有区别了。拿int举例。如果外部传入的是一个装箱后的int那么Expression.Convert到int是完全没问题的它可以拆箱。但如果外部传入的是一个long或者double即使它们内部可以隐式转换到int表达式树也不会自动帮你做数值转换。你要么提前把参数改成正确的类型要么在传给工厂前自己完成转换。我在实践里的经验是调用方最清楚自己传的是什么工厂类不要做强类型的猜测。另外引用类型参数也很容易踩坑。比如构造函数参数类型是string外部却传了一个StringBuilderExpression.Convert在执行时会尝试把StringBuilder转成string结果必然失败。所以在选择构造函数时最好利用Type.IsAssignableFrom做一层过滤选出真正兼容的那个而不是只按参数个数蒙。3.3 缓存表达式树避免重复编译表达式树如果每次调用都现场构建并Compile()性能优势就全丢了。编译操作本身有开销第一次编译消耗可能是普通构造调用的几十倍。正确的做法是把编译结果保存在静态字段或字典里。上面代码里的_creator是static readonly意味着每个泛型闭合类型比如GenericFactoryCustomer在整个进程生命周期里只编译一次。这已经覆盖了大多数使用场景。如果你要处理的是完全动态的类型没法写在泛型参数里那就需要一种按Type缓存Funcobject?[], object的字典。常见的实现是private static readonly ConcurrentDictionaryType, Funcobject?[], object _cache new ConcurrentDictionaryType, Funcobject?[], object(); public static object Create(Type type, params object?[] args) { return _cache.GetOrAdd(type, BuildFactory)(args); } private static Funcobject?[], object BuildFactory(Type type) { // 构建逻辑与上面泛型类基本一致只是返回值不强制为 T }用ConcurrentDictionary.GetOrAdd可以减少多线程下重复编译的竞争同时保证缓存查询性能足够好。如果你在某个框架里需要频繁动态创建类型我通常不会直接用泛型静态类而是用这种字典缓存版本因为它的适用范围更广。4. 性能对比表达式树工厂比反射快在哪儿4.1 三种常见方案的成本模型在谈性能之前先明确一点直接new Customer(...)是永远最快的方式因为它连委托跳转都不需要。表达式树的优势是在“无法直接写new T(...)”的前提下尽可能逼近直接调用的性能。我们可以把常见方案的调用开销简单列一下直接构造调用编译期确定构造函数几乎零额外开销。表达式树编译后的委托首次编译较慢后续调用是委托调用参数类型要经过object装箱/拆箱但整体成本可控。Activator.CreateInstance每次调用都要动态解析构造函数、包装参数数组、做安全检查和异常处理开销大得多。反射ConstructorInfo.Invoke和Activator类似甚至更慢因为少了内部的一些缓存优化。从成本模型上看表达式树工厂的收益集中在“高频调用 动态类型”这个组合里。如果调用次数很少比如一秒钟只创建几个对象用Activator反而更省心代码也更短。4.2 为什么编译后的委托比反射快我们可以从 IL 的视角来理解。Activator.CreateInstance内部调用构造函数时需要做一层层解释性的操作找构造函数、匹配参数、格式化异常最后才能真正执行构造逻辑。而表达式树编译出的委托Compile()生成的方法是直接把参数数组里的元素拆箱、转型然后调用构造函数。两者在 IL 层面上的差距非常明显。用大白话说反射是“边看菜谱边做菜”表达式树是把菜谱背下来直接进入烹饪流程。菜谱看一次和看一万次的差距就是性能差的来源。当然表达式树的收益也不是完全没有代价。如果你构造表达式的过程本身很复杂比如每次都要用GetConstructors()去扫描类型成员那么这部分开销会被计入首次解析。所以我才强调缓存的重要性。缓存做得好的表达式树工厂性能可以做到比反射快一个数量级缓存做得不好反复编译表达式树甚至可能比反射更慢。4.3 什么时候不该用这套方案写到这里我想泼一盆冷水。表达式树不是银弹有些场景不该硬上。如果类型本身有稳定的无参构造函数并且初始化可以通过属性赋值完成直接用new T()配合泛型约束是最简单的。这时候上表达式树属于过度设计。如果类型只有内部构造函数而且你真的有权修改这个类型那么更推荐在类型内部提供一个工厂方法或静态创建方法让调用方通过委托传入。这样一来强类型和语义清晰度都远胜表达式树。还有如果泛型参数只是用来约束接口或抽象基类工厂类实际上不应负责创建具体实现。这种职责更应该交给依赖注入容器或注册表。表达式树适合的是“你已经拿到一个具体Type需要在运行时动态构造它”的场景它不应该替你承担架构设计上的职责。5. 常见问题与排查实战记录5.1 Expression.New 参数与构造函数签名不匹配这是最容易犯的错。Expression.New(ctor, args)里的args数量和顺序必须与ctor.GetParameters()完全一致。如果少了参数或者表达式中的某个参数类型不能隐式转换到构造函数参数类型Compile()时不会立即报错但在表达式树创建阶段可能就会抛出参数异常甚至拖到运行时才炸。我排查这个问题的顺序很简单先把ctor.GetParameters()的所有参数类型打印出来再用同样的顺序去拼argumentExpressions两个列表放一起对比。九成的问题都出在“反射到的参数顺序”和“外部传入的数组顺序”不一致。解决方案也很直接调用方传参时必须严格按构造函数的参数顺序来工厂类不要试图重新排序。5.2 泛型参数是抽象类或接口如果一个类型是abstract或者interfaceGetConstructors()返回要么是空要么只包含保护构造器。这种情况下表达式树没法创建实例因为根本不存在可调用的实例构造函数。我见过不少同学在这里卡住然后开始给工厂加各种类型判断。我的建议是如果业务上允许用具体类型就让工厂接收一个具体类型的Type参数如果确实只能拿到抽象类型那说明设计里缺少“从抽象类型解析具体实现”的一步这一步应该在更上层完成而不是塞进表达式树工厂里。5.3 值类型与可空类型泛型参数T有可能是值类型比如GenericFactoryint。int 的构造函数就是无参默认构造用Expression.New创建会有特殊性。更常见的是构造函数参数中包含可空值类型比如decimal?。Expression.Convert从object转decimal?的语义我前面提过它可以工作但要小心外部传入的null。对可空值类型来说null是合法值所以我在代码里的空值保护不会触发Expression.Default而是正常走Convert。别在空值处理后对可空类型再强制转成基础值类型那样反而会把合法的空值破坏掉。5.4 构造函数数量不止一个时如果类型有两个构造函数一个接收string另一个接收int而外部传进来的数组是空或者参数个数相同但类型不同工厂就需要更聪明的匹配策略。我的做法是在首次构建时遍历所有公共构造函数先用参数个数过滤再用Type.IsAssignableFrom逐个判断每个参数是否兼容。如果最终候选构造函数多于一个就选择参数类型“最具体”的那个。这里的“最具体”可以通过类型继承关系判断但大多数时候只需要按传入参数的实际类型做一次精确匹配就够了。如果实在无法匹配我会抛出一个带详细信息的异常把可用构造函数列表和实际传入参数类型都列出来方便调用方排查。这样看起来代码啰嗦但能在线上环境省下很多时间。6. 我踩过几次坑之后的选择最后聊点私货。起初我做这类动态实例化第一反应就是反射觉得Activator.CreateInstance一行代码搞定何必折腾表达式树。后来在真实的高频场景里一压测发现反射方案成了瓶颈才回过头来研究表达式树。等我真正把Expression.New和Compile组合跑通之后我发现难的不是代码本身而是之前对“表达式树到底在解决什么问题”理解得不够。如果你正准备在项目里复用这篇文章里的思路我会建议你先写一个小型性能测试拿你的真实类型跑一遍Activator和表达式树工厂的对比。你大概率会看到明显的差距也会更理解为什么很多框架底层宁可花力气缓存表达式树也不愿意频繁反射。至于要不要用Expression.New之外的花活比如复杂初始化逻辑、调用实例方法后再返回对象我真心建议保持克制。表达式树一旦复杂起来排查难度是成倍上升的。这篇文章里给的工厂类是我自己会采用的保守版本按类型缓存编译结果、构造函数匹配做到够用、参数转换明确。你完全可以在这个基础上继续扩展。只要记住表达式树的价值不是“看起来高深”而是让动态创建这件事从解释型变成编译型这种性能上的手感差异只有真的跑过一轮压测才能感受到。