上个月我接手了一个老项目的维护任务几百个Excel模板文件需要按字段配置动态导出底层实现走的是反射读取实体属性、按名称取值、拼接报表。数据量一上来单次导出几十万行CPU直接顶满一次导出要跑大几十秒。测试同事反馈的工单标题写着“导出慢得离谱求优化”。我把热点挨个点了一遍——普通循环、对象池、并行导出都试过效果有限。后来抱着试一试的心态把高频调用的反射取值换成了dynamic属性访问。改动不到15行导出时间肉眼可见从40多秒缩到了10秒上下。这个结果让我重新审视一个被骂了十多年的C#特性C#的dynamic。这篇文章不是标题党式的吹捧也不是要你全项目无脑上dynamic。我想结合这次线上优化的真实数据、DLR底层原理以及我把反射改成dynamic时踩过的那些坑把动态类型这件事讲透。无论你是在做ORM、写数据导出组件还是搞插件系统这篇都能给你点实际参考。1. dynamic的性能污名是怎么来的1.1 从C# 4.0说起dynamic承受了太多误解C# 4.0在2010年正式引入dynamic关键字官方主推场景是Office COM互操作和与Python、Ruby这类动态语言的协作。当年C#开发者对“静态类型”的信仰根深蒂固dynamic一出现就被很多人定性为“破坏类型安全的旁门左道”。更麻烦的是早期.NET Framework上的DLR实现确实不算快再加上很多博客拿dynamic和静态类型做基准测试结论清一色是“dynamic比静态调用慢几十倍”。这些测试的对比对象就不公平——拿动态绑定和直接硬编码的方法调用比那当然慢。但大家真正关心的场景是“运行时才知道类型和成员”的动态调用。在这个场景下dynamic的对手不应该是直接调用而是反射。于是“dynamic很慢”这个结论就被当成公理流传了下来。我在Excel导出优化之前也是这么想的直到实测数据摆到面前才发现这个标签贴了十几年摘下来还需要点勇气。1.2 真正慢的从来不是dynamic而是错误的使用姿势我复盘过网上很多“dynamic性能拉胯”的案例发现一个共同点调用方式几乎都是在一个循环里反复创建新的dynamic表达式或者每次传入不同类型的对象导致DLR的调用点缓存CallSite缓存完全失效。举个例子有人这样写for (int i 0; i 10000; i) { dynamic d GetObject(i); // 每次返回不同类型 var x d.Name; // 每次都走完整绑定流程 }每次返回不同类型DLR的规则缓存就命中不了绑定器的元数据解析、类型判断、策略生成全部重来一遍性能必然灾难。可是这锅不该dynamic背——缓存机制设计出来就是为了处理“同一调用点、相同类型”的热路径你偏要反着用它快不起来才是正常的。真正合适的用法是把dynamic对象稳定绑定到一个变量上保持同类型复用同一个CallSite。这时候DLR的能量才真正释放出来。2. 底层机制拆解DLR调用点缓存凭什么比反射快一个量级2.1 反射Invoke的每一步都在重复劳动先看反射为什么慢。很多人的反射代码长这样var value obj.GetType().GetProperty(Name).GetValue(obj);这段代码每一部分都在做开销很大的事GetProperty(Name)运行时遍历类型的元数据结构按字符串比对方法名可能还有属性遍历、访问器查找、重载比对。即使只执行一次也远比一个静态方法调用昂贵。GetValue(obj)把参数打包成object[]做参数类型匹配、访问权限校验、可见性检查值类型还要装箱最后把返回值再装箱成object。每一项检查在每次调用时都要重来一遍没有任何缓存机制。如果代码里再叠加运行时字符串拼接生成方法名那更是雪上加霜——GetMethod本身就是重量级操作频繁调用会拖垮整个循环。最关键的是反射的Invoke每次调用都完整地做一遍“发现成员→校验→调用”的流程不存在任何状态记忆。这不只是“慢一点”的问题而是算法层面的重复劳动。2.2 编译器为dynamic生成了什么当我们写下dynamic d person; var name d.Name;编译器在后台生成一个CallSiteT这是一个泛型调用点用于承载“某个位置上的动态成员访问”的状态。整个调用流程大致如下第一次执行到d.Name时运行时触发绑定器Binder.GetMember拿到对象的真实运行时类型假设是Person然后生成一条规则如果运行时类型是Person就直接访问Person.Name属性最后把这个规则编译成一段快速的委托。规则缓存到调用点上。后续执行同一个CallSite时先做一次类型判断命中规则后直接进入快速路径执行属性访问跳过了所有字符串查找、校验、装箱等步骤。从执行结果看d.Name命中缓存后性能已经非常接近直接的属性读取——反射的GetValue则永远停留在“完整检视”的阶段。这里有个点值得强调dynamic并没有“替代”反射它在底层其实也做了类似“找成员”的动作只是把结果缓存了下来后续直接复用。反射的问题在于不缓存每次都重复投入。2.3 第一次慢、之后快规则缓存是怎么工作的DLR在调用点上有两级缓存L0线程本地专用缓存命中速度极快 L1进程级共享规则缓存多个线程可复用第一次绑定的成本不低因为要完成类型解析、规则生成甚至表达式编译。但一旦缓存建立后续调用的开销就只剩下“与缓存规则比对类型”这一个动作。实测下来同一个CallSite上连续调用相同签名的方法后面每调用的耗时和直接调用已经接近到个位数的纳秒级差距。所以理解dynamic性能的前提是如果你让它的CallSite存活得足够久、调用类型足够稳定它才能真正快起来。这也是我在Excel导出优化中体验最明显的地方——几十万行数据反复读取同一个Person对象的Name属性CallSite稳稳命中性能自然就上去了。3. 实测对比一个真实的按名取值优化案例3.1 测试场景与代码我拿一个简化的实体类做基准测试基本还原项目里的按名取值场景public class Person { public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } }测试方法分别用普通反射、缓存PropertyInfo后的反射、dynamic三种方式读取100万次Name属性var sw new Stopwatch(); var person new Person { Id 1, Name 张三, Age 30 }; var prop typeof(Person).GetProperty(Name); int iterations 1_000_000; // 普通反射每次循环内GetProperty GetValue sw.Restart(); for (int i 0; i iterations; i) { var v person.GetType().GetProperty(Name).GetValue(person); } sw.Stop(); Console.WriteLine($普通反射: {sw.ElapsedMilliseconds}ms); // 缓存PropertyInfo sw.Restart(); for (int i 0; i iterations; i) { var v prop.GetValue(person); } sw.Stop(); Console.WriteLine($缓存PropertyInfo: {sw.ElapsedMilliseconds}ms); // dynamic sw.Restart(); dynamic d person; for (int i 0; i iterations; i) { var v d.Name; } sw.Stop(); Console.WriteLine($dynamic: {sw.ElapsedMilliseconds}ms);我在自己工作机上跑出来的参考数据大概是这样环境是.NET 8Release模式方式100万次耗时相对耗时普通反射每次GetProperty2100ms约85倍缓存PropertyInfo后GetValue720ms约29倍dynamic重复调用同一CallSite105ms约4倍直接调用基准线25ms1倍注意不同CPU、不同.NET版本下具体数字会变但数量级关系是稳定的。dynamic在“按名取值”这条热路径上相比缓存PropertyInfo后的反射仍有7倍左右的差距——这就是标题里“300%”的来源实测甚至不止。3.2 数据结果解读这个结果说明三件事第一普通反射的慢一大半来自反复GetProperty。只要你把PropertyInfo缓存下来性能已经有了质的提升。很多人其实没有意识到这点一直在反射性能的崩溃边缘裸奔。第二即使缓存了PropertyInfoGetValue本身还是很重。GetValue不仅仅是字段读取它还涉及参数包装、校验、装箱拆箱。第三dynamic的最大优势在于它的缓存是自动的。编译器生成的CallSite会自动缓存规则你不用手工缓存任何元数据性能就自动逼近直接调用。3.3 什么情况下dynamic没有赢理性看待300%我必须诚实地说如果你在反射那一侧把技术用到极致dynamic不一定永远赢。比如用ExpressionTree编译一个强类型委托或者用Delegate.CreateDelegate缓存委托后直接调用性能会优于dynamic甚至逼近硬编码调用。我测试了一个版本var getter (FuncPerson, string)Delegate.CreateDelegate( typeof(FuncPerson, string), prop.GetMethod);然后循环调用getter(person)耗时大约在30ms上下和直接调用差距很小。那dynamic的价值在哪在于通用性。当你开发一个通用框架、面对成百上千种类型、无法在编译期预知具体成员签名时你没法轻易CreateDelegate——因为委托的类型参数在编译期就是未知的。这时候dynamic用极小的代码成本提供了“接近委托缓存”的性能这是反射GetValue做不到的。所以我建议把dynamic和反射的对比分成两个层面看如果成员的签名在编译期已经确定优先选择委托缓存或表达式树而不是dynamic。如果成员是运行时才知道的未知类型dynamic是你几乎唯一能把性能和开发效率同时兼顾的方案。4. 什么场景该上dynamic什么场景该老实反射4.1 适合dynamic的典型场景典型场景一通用数据导出租户场景中的属性读取。你有几十个实体类、几百个属性代码不知道运行时会绑定哪个属性但不妨大量循环遍历同类型对象的同一个属性。这正是老项目Excel导出遇到的情况。改成dynamic后开发量变化很小性能却飞涨。典型场景二插件系统调用外部模块的方法。插件实现了某个接口但类型在编译期不可见反射调用繁琐且慢直接dynamic调用可以省掉大把样板代码。典型场景三与COM对象或动态语言对象互操作。Office COM组件调用是dynamic的设计初衷用dynamic写比反射顺手太多性能也在接受范围内。4.2 必须用反射的场景有几种情况dynamic帮不上忙只能回反射运行时才知道成员名字的字符串。比如用户配置了一个字段名“Age”你需要从对象中取出这个字段的值。dynamic的调用点在编译期就确定了成员名不支持“用字符串变量访问属性”。这种情况要么反射缓存PropertyInfo要么用表达式树动态编译。访问私有成员或内部成员。DLR绑定器基于类型的公共可见成员做绑定对private方法默认直接RuntimeBinderException。调用泛型方法并显式指定泛型参数。dynamic调泛型方法时无法在调用点显式写d.MyMethodint()编译器会直接报错只能反射MakeGenericMethod。NativeAOT等提前编译场景。DLR依赖运行时生成代码AOT环境下基本不可用这时候反而应该用反射虽然性能差但至少能跑。4.3 一句话选型建议选型核心就一句“编译期能确定的尽量别用反射也别用dynamic运行期必须动态的能用dynamic就用dynamic万不得已才上反射。”很多人把dynamic当成反射的“性能版”但实际上适用范围并不完全重叠。想清楚边界再动手改起来才不慌。5. 保姆级避坑指南我踩过的七个dynamic坑5.1 坑一字符串方式访问成员dynamic帮不上忙这一点最容易被误解。很多人以为dynamic支持“运行时用字符串变量指定属性名”就像Python的getattr(obj, name)。实际上C#的dynamic调用点在编译期就把成员名“写死”了。你写d.Name编译器把这个成员名字符串“Name”放进调用点它不会因为运行时变量变化而变化。string propName Age; dynamic d person; // 下面这行无法实现按字符串取值 // var v d[propName]; // 不行除非对象实现索引器 // var v d.propName; // 编译器按“propName”这个成员名去绑定不是取变量值如果是ExpandoObject或JObject这类实现了IDynamicMetaObjectProvider的对象可以通过索引器访问但那是对象自身的能力不是dynamic语法带来的。真正需要“运行时任意字符串访问成员”时老老实实用反射缓存PropertyInfo或者用表达式树做属性访问器缓存。5.2 坑二泛型方法无法用dynamic显式指定类型参数假设有一个泛型方法public T ConvertT(object input);用dynamic调用时没法写dynamic d converter; var result d.Convertint(input); // 编译错误编译器会报错因为dynamic调用不支持显式指定泛型类型参数。如果想实现类似效果只能走反射var method converter.GetType().GetMethod(Convert).MakeGenericMethod(typeof(int)); var result method.Invoke(converter, new object[] { input });这种场景反射反而不慢——因为方法信息可以缓存起来但dynamic在语法上直接没有入口。遇到泛型动态调用的需求别死磕dynamic。5.3 坑三私有成员、内部成员、扩展方法绑定器的“盲区”DLR绑定器遵循普通C#成员可见性规则。d.PrivateMethod()直接抛Microsoft.CSharp.RuntimeBinder.RuntimeBinderExceptioninternal成员在不同程序集里也一样。这种情况用dynamic连编译期错误都换不来纯增加运行时排查成本。还有一个大坑扩展方法不参与动态绑定。d.Where(x x 0)如果d是dynamic编译器不会去搜索静态扩展类上的方法而是尝试在d的运行时类型实例方法上找Where大概率抛异常。解决办法是先把dynamic转成IEnumerableT之类的静态接口再调用扩展方法。5.4 坑四重载决议在运行时“偷偷变卦”C#的静态重载决议是编译期确定的dynamic则是运行时按实际类型重新选一遍。void Foo(int x) { Console.WriteLine(int); } void Foo(string x) { Console.WriteLine(string); } object obj 42; dynamic d obj; Foo(d); // 运行时解析为 Foo(int)表面上看没问题。但当你动态调用一个类的方法时如果传入的实参运行时类型和你预期不一样可能选到完全不同的重载调试起来非常痛苦。因为编译器不会帮你检查只有跑到那行才暴露出来。我的经验是dynamic调用点不要包裹在复杂的重载链中能先声明成具体类型就先转具体类型否则潜在的重载选择问题会像地雷一样埋在代码里。5.5 坑五值类型装箱、结构体大对象、规则爆炸dynamic本质上是把任何类型包装成object处理值类型每次赋值、访问都涉及装箱拆箱。如果代码在循环里反复操作ListGuid、byte[]这类高密度数据dynamic的性能优势会被装箱开销抵消甚至反噬。更隐蔽的是“规则爆炸”。同一个CallSite上如果被传入多种不同类型的参数对象DLR会频繁生成新规则缓存空间被撑满后规则可能被反复淘汰重建。在“异构集合”的循环里用dynamic性能可能比反射还拉胯。Listobject mixed new Listobject { new Person(), new Car(), new Order() }; foreach (var item in mixed) { dynamic d item; d.Name ; // 每次触发重新绑定 }这种代码就该考虑用接口统一抽象而不是靠dynamic硬撑。DLR的缓存机制决定了“对相同类型做重复调用”才是最佳使用姿势。5.6 坑六AOT/Trim环境下直接废掉如果你未来要把项目切到NativeAOT或者发布到iOS这类不允许JIT的环境dynamic一定要提前排查。NativeAOT在编译期需要静态分析所有代码路径但DLR需要在运行时动态生成和编译表达式两者根本矛盾。真实表现是编译期可能就报错或者发布后在dynamic调用点直接崩溃。相比之下反射在AOT下虽然也有裁剪风险但配合DynamicDependency等特性还有挽回余地。如果目标是AOTdynamic不是一个值得冒险的方案。5.7 坑七异常信息、排查成本与编译期保护的缺失dynamic把“编译期检查”变成了“运行时绑定”。属性名拼错不会在编译期报错而是运行到那行直接抛RuntimeBinderException。这还不是最痛的点——真正的痛在于RuntimeBinderException的调用栈信息在多重动态调用链中经常只显示入口定位“哪个属性名错了”要靠日志和局部变量观察。dynamic调用里面的方法抛出异常不会像反射那样包一层TargetInvocationException而是直接把原始异常抛出来乍一看少了干扰项但如果你习惯了反射的异常模式很容易误判调用位置。大规模重构时改一个属性名项目里的dynamic调用点不会像静态代码那样报编译错误只有在测试跑到的路径上才会崩。我的补救手段dynamic调用点强制包一层带上下文的try-catch日志里记录当前对象类型和调用的成员名至少要留出可排查的尾巴。5.8 一张表收尾动态/反射各场景选型对照使用场景推荐方案理由循环内按已知属性名/方法名调用dynamic自动缓存规则性能好代码少运行时才知道成员名字符串反射PropertyInfo缓存dynamic语法不支持字符串成员名调用未知类型的公共接口方法dynamic省去接口转换和反射样板私有/内部成员访问反射dynamic绑定器不透明访问非公共成员泛型方法且需指定泛型参数反射 MakeGenericMethoddynamic无法显式指定泛型参数COM/Office互操作dynamic语法简洁设计初衷NativeAOT发布场景反射配合AOT特性DLR不兼容AOT异构对象集合中批量调用同名方法接口/基类抽象避免规则爆炸和反复绑定6. dynamic之外的下一步6.1 表达式树编译委托动态调用的性能天花板如果某项动态调用是系统瓶颈而且你能预知方法的签名比如固定参数个数、固定参数类型最暴力的优化是用表达式树编译一个强类型委托缓存起来public static Funcobject, string BuildGetter(Object target, string propertyName) { var param Expression.Parameter(typeof(object), target); var cast Expression.Convert(param, target.GetType()); var property Expression.Property(cast, propertyName); var convert Expression.Convert(property, typeof(string)); return Expression.LambdaFuncobject, string(convert, param).Compile(); }这样每次调用只做一次类型转换和属性读取性能比dynamic更高适合“框架化、重复调用频率极高”的路径。代价是代码明显复杂而且一旦遇到方法重载、泛型参数、可选参数表达式树的复杂度会指数级上升。所以我的排序是简单场景用dynamic瓶颈场景上表达式树一般场景别乱折腾。6.2 用接口、基类、设计模式代替动态很多动态需求其实是设计缺陷的信号。如果一个集合里有Person、Car、Order都要读取Name属性为什么不定义INamed接口如果插件系统里所有插件都有Execute()为什么不抽象一个公共接口我在优化老项目时发现动态调用或反射代码密集的地方往往是当年图省事、绕过了类型设计的地方。能用接口解决的设计问题不要用dynamic补。dynamic应该是“类型系统表达不了的场景”的补充手段而不是常规武器。6.3 个人在实际优化中的体会我复盘这次Excel导出优化最大的感慨是性能优化前先搞清楚技术方案的真实能力边界。我原本也默认dynamic就是慢结果实测下来它在“同类型高频重复调用”场景里吊打反射和直接调用差距已经微乎其微。这几年C#的运行时也在持续改进.NET Core时代的DLR实现相比.NET Framework已经有明显进步再用十年前的印象给dynamic判死刑真的说不过去。如果你也要动这类代码我给你三个可直接落地的忠告先写一小段基准测试把你的真实业务场景跑出数据再决定改哪些点。不要听任何人说“dynamic快”或“dynamic慢”就直接上结论。改动只覆盖热路径非热路径保持原样。我这次只改了最内层循环里那两行反射取值外层逻辑一概没动回归成本极低。动态调用点一定要有日志和异常上下文不然线上出了问题排查时间可能比省下的那几秒导出时间贵得多。技术的锅往往是使用姿势的锅。dynamic背了十几年的黑锅也该在真实数据面前翻身了。