前阵子在做一个数据对接模块时对方的接口返回结构经常变化今天多一个字段明天把一个对象改成数组用强类型类去接的时候每次都要改模型、改映射、改序列化逻辑改到最后我自己都烦了。后来静下心把一部分代码用 C# 的dynamic重写代码量直接少了一半而且结构变了不用再重新编译。这次经历让我彻底重新审视了动态编程在 C# 里的价值也踩了不少坑。这篇就当作一次复盘式分享适合对dynamic停留在听说过、不敢用阶段的人也适合已经在用但被运行时报错折磨过的开发者。我会尽量说清楚它解决了什么问题、底层怎么工作、实际用在哪些地方最值、性能代价有多大以及那些文档里不会写的坑。1. 先搞清楚dynamic 不是延迟声明的 var1.1 var、object 与 dynamic 的真实差异很多初学者把var和dynamic混为一谈觉得都是不用写类型。实际上两者的底层逻辑完全不同用错地方是要出事故的。var只是“让编译器帮你推断类型”推断完以后变量仍然是强类型。比如你写var num 1;编译器知道它是int后续num的所有操作都按int绑定类型检查发生在编译期。object就更不一样了它是所有类型的基类能把任何东西装进去但一旦装进去编译器只认它是object。你写object x GetData(); x.Foo();编译直接报错因为object类型上根本没有Foo方法除非先强制转换。dynamic则是把“类型检查/方法绑定”这一整套动作从编译期推迟到了运行期。编译器看到dynamic类型的表达式时不进行常规的静态绑定而是生成一段特殊的动态调用代码等程序真正跑到那一行时再由运行时机制去解析实际类型并调用对应成员。所以写dynamic d GetData(); d.Foo();编译能通过但如果GetData()返回的对象没有Foo方法运行时会抛出异常。我做了一个极简对照表方便大家直接记关键字类型检查时机实际类型成员调用绑定典型用途var编译期静态推断的类型静态绑定局部变量简化声明object编译期装箱后的引用类型静态绑定仅基类成员通用容器需显式转换dynamic运行期任意类型运行时动态绑定跨语言、反射替代、动态结构数据1.2 静态绑定与动态绑定的执行模型用一句大白话类比静态绑定就像你拿着标准插头去插座插口形状是固定的插不插得进去在出厂时就决定了动态绑定则是到了现场才看插头形状然后现场决定怎么接。C# 默认是强类型、静态绑定语言绝大多数情况下这是优点IDE 智能提示、编译期类型安全、重构工具能精确追踪引用。代价是灵活性差遇到“对象结构在运行时才确定”的场景写静态类型代码会非常别扭。要么定义一堆用处不大的 DTO 类要么写大量反射代码去动态读取属性、动态调用方法。dynamic最大的价值就是把静态绑定语言的灵活性短板补上。它不是为了取代强类型而是服务于“边界型”场景程序边界的数据结构动态变化、需要调用动态语言写的组件、需要调用 COM 接口等。在这些场景里动态绑定带来的开发效率提升是显而易见的。这里要强调一个认知用dynamic不等于放弃类型安全而是把类型安全的把关责任从编译器移交给了运行时和开发者自己的测试。所以用它的地方应该尽量收敛、封装、隔离而不是满仓库到处飞。2. DLR 场景下的动态绑定底层到底发生了什么2.1 运行时绑定器与调用点缓存dynamic之所以能在运行期完成方法解析依赖的是 .NET 平台上的 DLRDynamic Language Runtime体系。DLR 不算一个新东西它最初是为动态语言在 .NET 上运行而设计的后来成了 C# 支持dynamic的基础设施。当编译器遇到一个包含dynamic表达式的操作时它会把这个操作标记为“动态调用点”。程序运行到这一行运行时不会直接硬编码调用某个方法而是通过一组“绑定器”去决策当前接收者的实际类型是什么要调用的方法叫什么参数有哪些重载决议怎么走绑定器拿到这些信息后生成一个能完成该调用的表达式树或委托然后去调用。为了提高重复调用效率DLR 有调用点缓存机制同一个调用点如果接收者类型和参数类型没变第二次会直接复用第一次的绑定结果。这有点像你在同一个门口反复刷卡第一次系统要验证指纹、查数据库之后同一张卡刷多了直接放行。所以dynamic的性能没有想象中那么差尤其是循环内对同一类型的对象做重复动态调用时缓存命中后的开销会明显下降。2.2 动态操作的类型边界哪里能用、哪里不能用dynamic表面上像“万能类型”但它有严格的行为边界不理解这些边界写起来会莫名其妙报错。动态调用只作用于“接收者”是dynamic的情况。如果接收者是普通强类型对象哪怕它的参数里有dynamic方法重载决议仍然参考强类型部分。扩展方法不能通过dynamic调用。因为扩展方法的静态绑定发生在编译期dynamic接收者会让编译器找不到扩展方法。这是实际开发中最容易踩的暗坑之一。dynamic不能用在某些语法场景不能作为泛型类型参数传递比如Listdynamic其实是不合法的不能用于ref和out参数上的动态绑定。lambda 表达式不能直接转换为dynamic也不能把dynamic直接作为表达式树类型使用。也就是说dynamic不是“去掉所有类型的限制”而是“特定环境下把绑定工作交给运行时”。认知到位了后续出了问题至少知道去哪里排查。3. 实战视角我把 dynamic 用在哪些地方最顺手3.1 用 dynamic 替代反射模板代码的终结反射是 C# 开发者绕不开的工具但反射代码写起来是真的啰嗦。以前我需要动态读取一个对象的属性值代码通常是这样的var obj GetSomeUnknownObject(); var prop obj.GetType().GetProperty(Name); var value prop?.GetValue(obj);如果还要继续动态调用方法或者处理嵌套属性代码会膨胀得非常快而且全是字符串一旦属性名拼错运行期才报错排查起来很痛苦。同样的事情用dynamic写一行就够了dynamic d GetSomeUnknownObject(); string name d.Name;我实际重构过一个内部工具模块原来用反射做属性遍历、方法调用和对象状态导出大概两百多行核心逻辑被反射 API 的样板代码淹没。改造成dynamic之后核心逻辑缩到了几十行可读性提升非常明显。当然这里有一个前提接收者对象的成员结构是相对稳定的只是编译期无法表达而不是“每个对象的字段完全随机”。有人会质疑反射至少能在字符串出错时给你机会用常量名dynamic写错了名字也是运行期报错一样有风险。对但从我的经验看dynamic代码的阅读负担和修改成本比反射低不少而且 IDE 调试时能看到动态调用的实际值。3.2 动态结构数据JSON 与 ExpandoObject现在做后端接口对接JSON 几乎是绕不开的。第三方接口返回结构不稳定的情况太常见了。配合 Newtonsoft.Json 时dynamic处理 JSON 非常舒服dynamic data JsonConvert.DeserializeObjectdynamic(jsonString); var customerName data.customer.name; var firstOrder data.orders[0];如果是System.Text.Json默认不支持直接反序列化成dynamic但可以配合JsonElement、ExpandoObject实现类似效果。我个人更常用的方案是把 JSON 先解析成ExpandoObject这样既能动态读写又能拿到字典视图using System.Dynamic; using System.Text.Json; var doc JsonDocument.Parse(jsonString); var expando new ExpandoObject(); foreach (var prop in doc.RootElement.EnumerateObject()) { expando.TryAdd(prop.Name, prop.Value.ToString()); }ExpandoObject是特别适合动态场景的容器它的属性本质上是字典的键值对你可以随时增删属性也能和dynamic无缝配合。做规则引擎、配置中心、数据映射层时用它比定义一堆半固定的 POCO 灵活得多。如果你在用 Newtonsoft.Json 的JObject还有一种更省事的路径直接把JObject用ToObjectdynamic()转换后续读属性就和操作对象一样自然。JObject本身就是动态结构内部实现也基于字典这类深度集成让 JSON 的动态处理变得非常顺手。3.3 COM 互操作与脚本语言对接another 场景是 COM 互操作。比如用 C# 操作 Office 组件时Application对象的方法和属性多到吓人如果全用强类型接口调用一长串 Cast、InvokeMember 能把代码写成天书。用dynamic之后dynamic excel Activator.CreateInstance(Type.GetTypeFromProgID(Excel.Application)); dynamic workbook excel.Workbooks.Add(); dynamic sheet workbook.Sheets[1]; excel.Visible true;读起来几乎和 VBA 一样直观。不过在服务端环境操作 Office 组件本来就不推荐仅作客户端自动化工具时体验很不错。与动态语言互操作时dynamic更是刚需。用脚本引擎加载 JavaScript 或 Python 代码时返回的结果往往没有静态类型直接dynamic接收然后按属性名访问省去一堆强制转换和类型探测。我在一个数据处理工具里接入了某个脚本运行时dynamic在这里的价值是无可替代的——强类型系统根本无法静态描述一个动态脚本对象的形状。3.4 数据驱动配置让配置项自己长出来做配置中心的时候以往的做法是定义一张配置类每个配置项一个属性每次加配置都要改代码。用dynamic加ExpandoObject可以实现配置项动态扩展dynamic config new ExpandoObject(); config.TimeoutSeconds 30; config.RetryCount 3; config.EnableFeatureX true;后续从数据库或配置中心加载时直接动态挂属性代码层面不需要为“多了一个新配置项”而重新发布版本。当然这只是表面上的“动态”维护成本需要靠规范和文档控制。4. 性能账单dynamic 的代价与我的优化取舍4.1 一组不完全严谨但很有参考价值的基准数据很多开发者一听到dynamic第一反应是“性能差”。确实有差距但差多少、差在哪里值得用数据说话。我在一个离线批处理模块里做过一次基准对一个普通对象执行一万次属性读取分别用三种方式静态绑定、反射、dynamic。结果很典型静态绑定是最快的反射最慢dynamic介于两者之间而且比反射快出不少。有一次的实测结果是dynamic约比静态调用慢 3 倍左右反射则可能慢一两个数量级。这不是严格意义的权威基准环境、CPU、运行时版本都会影响具体数值但结论方向是稳定的dynamic的损耗没有很多人口中那么夸张相比它的灵活性这点开销在很多业务场景里可接受。dynamic慢的原因主要有两块一是运行时绑定器要处理调用点决策即使有缓存第一次调用的开销仍然高于静态绑定二是值类型在动态调用中会发生装箱额外产生堆分配。但如果你的调用点命中缓存且接收者类型稳定后续开销远低于反射的GetMethod加Invoke。4.2 把动态边界收窄我惯用的封装手法看到上面的基准不要立刻把dynamic用到核心热路径上。我的原则是动态边界收窄动态结果快速转为静态。也就是说程序的核心领域模型和业务逻辑尽量保持强类型只在“外部接口、反射替代、动态数据源”这些边界层使用dynamic数据一进入内部马上转换、映射成具体的强类型模型。我在项目里常用的做法是做一个适配层把动态数据转换成领域模型public static OrderModel FromDynamic(dynamic raw) { return new OrderModel { Id raw.Id, Amount raw.Amount, CreatedAt DateTime.Parse(raw.CreatedAt.ToString()) }; }这样一个模块里只有边界代码能看到dynamic其余同事读代码时不用被动态类型干扰。更重要的一点隔离之后如果未来想把动态调用替换成强类型反序列化改动范围也被死死锁在适配层里。另外一个优化技巧是如果在循环里反复调用同一个动态对象的方法可以先把它转换成一个委托或一个强类型接口再做循环。比如动态对象里有一个Calculate(decimal)方法可以先取出来赋给Funcdecimal, decimal循环体内调用委托性能损失就降到几乎可以忽略。5. 那些年踩过的动态编程坑报错、重载与调试技巧5.1 RuntimeBinderException 的正确读法用dynamic最常碰到的就是RuntimeBinderException大意是“运行时绑定器无法找到匹配的调用”。报错信息通常长这样Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: object does not contain a definition for Foo乍一看很吓人但它其实是在说接收者对象的实际类型上找不到Foo这个方法或属性。排查第一步先确认接收者对象的实际运行时类型而不是看声明类型。调试器里直接给变量加监视展开Dynamic View就能看清动态对象到底有哪些成员。如果是 JSON 反序列化出来的打印一遍所有键值看是否存在嵌套层级或null值的问题。另一个常见情况是调用确实存在但方法签名不匹配。动态绑定对参数类型的匹配非常敏感比如期望int的地方你传了一个字符串绑定器也会判定为不匹配。这时候先给参数做一次显式转换通常就能救回来。5.2 重载选择、扩展方法与 LINQ 的几个深坑动态绑定下的重载决议有一套独立规则和编译期静态重载决议不完全一致。表现就是同一个调用用强类型写会走到 A 重载用dynamic写可能走到 B 重载。原因是绑定器在运行时按接收者实际类型、参数实际类型重新做一次重载选择而这个选择逻辑和编译期的规则有差异。遇到这种问题最稳妥的方案是给边界参数强类型化或者提前把动态参数Convert.ChangeType成目标类型主动引导重载决议。扩展方法那个坑前面提过再强调一遍dynamic接收者上不能调用扩展方法。有个很典型的例子dynamic list GetDynamicList(); var count list.Count(); // 报错因为 Count() 是 Enumerable 扩展方法这里你以为是调用了 LINQ 的Count()但运行时绑定器不认扩展方法直接就炸了。解决办法是先把dynamic转换成IEnumerableT再调用 LINQ。这个坑非常隐蔽尤其在代码 review 时不容易发现。把dynamic和 LINQ 混用也要小心。dynamic对象进不了普通的强类型表达式树查询如果你试图对Listdynamic做Where(x x.Prop 1)内部很容易出现运行时绑定失败因为表达式树里的节点类型是object属性访问无法正确解析。比较好的做法是先把动态对象映射为强类型数据再进入 LINQ 链路。5.3 调试动态代码的实用手段调试dynamic代码有一个核心心态不要把它当强类型用而是在每一个关键入口打印或观察接收者的真实类型和成员。用GetType()获取真实类型并配合反射打印成员列表快速确定动态对象具备哪些能力。在 Visual Studio 的监视窗口里展开动态视图能直观看到属性、索引器和方法列表。如果碰到某个动态返回结果怎么都调不通先赋值给object再强制转换成已知类型打破动态绑定的黑盒。日志里尽量记录调用对象的类型名、成员名和参数类型方便复现运行时绑定的失败现场。有一次我在排查一个 JSON 动态对象的问题时怎么都读不到某个属性最后发现是属性名大小写不一致服务端返回的是UserName我读的是username。绑定器按字符串名字匹配大小写非常严格这一点和反射一样容易中招。可以写一个小工具方法把动态对象的所有属性名统一输出到日志里一目了然。还有一点团队协作层面的经验动态代码要加清晰注释写清楚为什么这里用dynamic前提条件是什么。因为静态代码的约束一目了然动态代码则要依赖上下文约定。我一般会在动态调用的附近写一句“该结构由上游接口保证包含 %s 字段”这样后续维护者修改时至少知道契约在哪。结语前的一点私人建议如果你正在犹豫要不要用dynamic我的建议是先在边界场景小范围试不要一上来就重构核心领域模型。找一段反射调用最多的代码换成dynamic试试感受一下开发效率的变化同时注意观察性能和报错体验。等习惯了动态绑定的思维方式再逐步扩大使用范围。另外一个小技巧我至今保留了“动态调用失败就退一步打印结构”的习惯。每当遇到dynamic相关的运行时报错我不急着改代码而是先写一段临时逻辑把对象的动态视图完整输出看清楚再动手。这比对着报错信息瞎猜快得多。dynamic在 C# 里是一个很有用的工具但它更像一把锋利也能伤到手的刀。把它限定在明确边界、封装好、做好防范措施它会成为那些反射代码和动态数据场景里的“快捷键”。用过几轮之后你自然会形成一套自己的判断标准这个位置值不值得引入动态调用风险是否能接受。希望这篇复盘能帮你少走一些弯路。