dynamic 是 C# 4.0 引入的一个强大而特殊的类型。它允许我们编写在编译时绕过类型检查的代码，将类型解析、成员访问和操作的决议推迟到运行时。这为 C# 这门静态类型语言带来了前所未有的灵活性，尤其是在与动态语言、COM 组件或动态数据结构（如 JSON）交互时。
然而，强大的能力也伴随着巨大的责任。滥用 dynamic 会牺牲静态语言带来的编译时安全、性能和工具支持。
1. 什么是 dynamic？
从语法上看，dynamic 像一个类型关键字，可以用来声明变量、字段、属性、方法参数和返回类型。
// 声明一个 dynamic 变量
dynamic myVariable = "Hello, World!";
// myVariable 的运行时类型是 string
Console.WriteLine(myVariable.GetType()); // 输出: System.String
// 调用 string 类型的方法，编译时不会检查 .ToUpper() 是否存在
Console.WriteLine(myVariable.ToUpper()); // 输出: HELLO, WORLD!
// 赋一个不同类型的值
myVariable = 123;
// myVariable 的运行时类型现在是 int
Console.WriteLine(myVariable.GetType()); // 输出: System.Int32
// 对 int 类型执行自增操作
myVariable++;
Console.WriteLine(myVariable); // 输出: 124
// 尝试调用一个不存在的方法
// myVariable.NonExistentMethod(); // 编译通过，但在运行时会抛出 RuntimeBinderException
核心特性:
- 延迟绑定（Late Binding）: 对
dynamic类型对象的所有操作（方法调用、属性访问、运算符操作等）都不会在编译时进行检查。编译器会假定这些操作在运行时是有效的。 - 运行时决议: 真正的操作绑定发生在运行时。如果操作在对象的实际运行时类型上是有效的，代码会成功执行；否则，将抛出
RuntimeBinderException。
2. dynamic 的工作原理：DLR (Dynamic Language Runtime)
dynamic 的魔力背后是 动态语言运行时 (Dynamic Language Runtime, DLR)。DLR 是 .NET Framework 4 (及后续版本) 中引入的一套 API，它为 C# 的 dynamic 和其他动态语言（如 IronPython, IronRuby）提供了一个统一的运行时环境。
当编译器遇到一个对 dynamic 对象的操作时，它不会生成常规的 IL (Intermediate Language) 指令，而是：
- 打包操作: 将操作（例如，方法名
"ToUpper", 参数列表()) 打包成一个“调用点 (Call Site)”。 - 嵌入 DLR 调用: 生成调用 DLR 的 IL 代码。
- 运行时解析:
- 当代码执行到该调用点时，DLR 启动。
- DLR 的 绑定器 (Binder) 会检查
dynamic变量引用的对象的 实际运行时类型。 - 绑定器分析该类型，查找是否存在名为
ToUpper且无参数的公共方法。 - 如果找到，DLR 会调用该方法。
- 结果缓存: 为了性能，DLR 会缓存成功的绑定结果。对于同一个调用点，如果下一次
dynamic变量的运行时类型没有改变，DLR 会直接使用缓存的绑定信息，避免了重复的反射查找，极大地提高了后续调用的性能。 - 绑定失败: 如果在运行时找不到匹配的成员，DLR 就会抛出
RuntimeBinderException。
一句话总结: 编译器信任你会做正确的事，将验证工作的皮球踢给了运行时的 DLR。
3. dynamic vs object vs var 核心区别
这三者是初学者极易混淆的概念。一张表格可以清晰地展示它们的区别：
| 特性 | dynamic |
object |
var |
|---|---|---|---|
| 本质 | 静态类型，但行为像动态类型 | .NET 所有类型的基类 | 编译时语法糖 |
| 类型检查 | 运行时 | 编译时（但只能访问 object 的成员） |
编译时 |
| 成员访问 | 无需转型，直接访问 | 必须先显式转型为具体类型 | 直接访问，因为编译器已推断出类型 |
| IntelliSense | 不支持（IDE 不知道具体类型） | 支持（仅 ToString, Equals 等 object 成员） |
完全支持 |
| 错误暴露 | 运行时 (RuntimeBinderException) |
编译时（转型失败是运行时 InvalidCastException） |
编译时 |
代码示例对比
// 1. var: 必须在声明时初始化，类型由编译器在编译时推断并固定
var a = "I am a string";
// a.ToUpper(); // ✅ 编译通过，IntelliSense 可用
// a = 123; // ❌ 编译错误：无法将 int 赋给 string 类型的变量
// 2. object: 可以持有任何类型，但操作前需要显式转型
object b = "I am also a string";
// b.ToUpper(); // ❌ 编译错误：'object' 不包含 'ToUpper' 的定义
// ((string)b).ToUpper(); // ✅ 必须转型，转型失败会抛出 InvalidCastException
b = 123; // ✅ 可以赋不同类型的值
// 3. dynamic: 编译时放行所有操作，在运行时检查
dynamic c = "I am a dynamic string";
c.ToUpper(); // ✅ 编译通过，运行时执行成功
// c.NonExistentMethod(); // ✅ 编译通过，但运行时抛出 RuntimeBinderException
c = 123; // ✅ 可以赋不同类型的值
c++; // ✅ 编译通过，运行时执行成功
4. dynamic 的优雅使用场景
dynamic 不是用来替代静态类型的常规工具，而是在特定场景下解决问题的“瑞士军刀”。
场景一：与动态语言交互
这是 dynamic 最经典的设计初衷。例如，在 C# 中调用 IronPython 脚本定义的函数。
// 假设有一个 Python 脚本 (my_script.py):
// def add(a, b):
// return a + b
// 在 C# 中使用 IronPython 引擎
var engine = Python.CreateEngine();
var scope = engine.CreateScope();
engine.ExecuteFile("my_script.py", scope);
// 'scope' 是一个动态对象，我们可以直接调用脚本中定义的函数
dynamic pythonScope = scope;
int result = pythonScope.add(10, 20);
Console.WriteLine(result); // 输出: 30
优雅之处: 避免了复杂的反射 API，代码像调用普通 C# 方法一样自然、可读。
场景二：处理动态的 JSON 数据
当处理的 JSON 结构不固定，或者你只想快速访问其中几个字段而不愿意为其创建完整的、强类型的类时，dynamic 非常有用。
使用 Newtonsoft.Json 或 System.Text.Json 配合 ExpandoObject 可以轻松实现。
using Newtonsoft.Json;
using System.Dynamic;
string json = @"
{
'name': 'John Doe',
'age': 30,
'isStudent': false,
'courses': [
{ 'title': 'History', 'credits': 3 },
{ 'title': 'Math', 'credits': 4 }
],
'address': {
'city': 'New York',
'zip': '10001'
}
}";
// 将 JSON 解析为 dynamic 对象
dynamic person = JsonConvert.DeserializeObject<ExpandoObject>(json);
// 像访问普通对象属性一样访问 JSON 字段
Console.WriteLine($"Name: {person.name}"); // 输出: Name: John Doe
Console.WriteLine($"City: {person.address.city}"); // 输出: City: New York
// 遍历数组
foreach (var course in person.courses)
{
Console.WriteLine($"- Course: {course.title}, Credits: {course.credits}");
}
// 甚至可以在运行时添加新属性
person.department = "Computer Science";
Console.WriteLine($"Department: {person.department}"); // 输出: Department: Computer Science
优雅之处: 无需为千变万化的 JSON 结构定义死板的类，代码简洁，探索性强。
场景三：简化 COM Interop
在 dynamic 出现之前，与 COM 组件（如 Office 应用）交互需要处理大量复杂的类型、可选参数和 Missing.Value。dynamic 极大地简化了这一过程。
旧方法 (C# 3.0 及以前):
// object excelApp = new Excel.Application();
// excelApp.Workbooks.Open(filePath, Missing.Value, Missing.Value, ... /* 10多个Missing.Value */);
使用 dynamic 的新方法:
using Microsoft.Office.Interop.Excel;
var excelApp = new Application();
excelApp.Visible = true;
// dynamic 使得命名参数和可选参数的调用变得极其简洁
dynamic workbook = excelApp.Workbooks.Add();
dynamic sheet = workbook.ActiveSheet;
sheet.Cells[1, "A"] = "ID";
sheet.Cells[1, "B"] = "Name";
sheet.Cells[2, "A"] = 1;
sheet.Cells[2, "B"] = "Alice";
// പഴയ COM API 中的方法 Get_Range 现在可以直接作为属性访问
dynamic range = sheet.Range["A1", "B2"];
range.Font.Bold = true;
range.Interior.Color = XlRgbColor.rgbLightBlue;
优雅之处: 代码更接近 VBA 的风格，可读性大大提升，摆脱了 Missing.Value 的噩梦。
场景四：作为反射的简洁替代方案
当需要动态调用一个对象的私有或公共成员时，反射 API 语法繁琐。在某些情况下，dynamic 可以提供更简洁的语法（通常配合 private 访问器或测试框架）。
public class Calculator
{
private int Add(int a, int b) => a + b;
}
var calc = new Calculator();
// 方法一：使用反射
var methodInfo = typeof(Calculator).GetMethod("Add", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance);
var result1 = (int)methodInfo.Invoke(calc, new object[] { 5, 3 }); // 语法繁琐
// 方法二：使用 dynamic (需要一些技巧，比如使用 PrivateObject 模式，或在测试中)
// 注意：直接 dynamic c = new Calculator(); c.Add(5,3); 是不行的，因为 Add 是 private 的。
// dynamic 可以和一些库（如 Impromptu-Interface）结合，来简化对私有成员的访问，
// 但更常见的场景是，当对象本身就是动态返回时，其内部调用机制已经处理了这些。
// 这里的关键是展示语法上的可能性，尽管直接访问私有成员通常不被鼓励。
// 一个更实际的例子：当一个方法返回 dynamic 时
public dynamic GetCalculator()
{
// 在这里可以返回一个实现了特定接口的匿名类型或 ExpandoObject
return new Calculator(); // 简化示例
}
dynamic dynCalc = GetCalculator();
// 如果 dynCalc 是一个知道如何调用私有方法的动态代理，那么下面的代码是可能的。
// 但更典型的场景是，返回的对象本身就是一个公共接口的动态实现。
优雅之处: 当与动态代理或 ExpandoObject 结合时，可以提供比反射更清晰的调用语法。
场景五：使用 ExpandoObject 创建动态对象
System.Dynamic.ExpandoObject 是一个神奇的类，它允许你在运行时动态地添加和移除成员（属性和方法）。
dynamic employee = new ExpandoObject();
employee.Name = "Jane Smith";
employee.Age = 28;
// 添加一个方法 (委托)
employee.DisplayInfo = (Action)(() =>
{
Console.WriteLine($"{employee.Name} is {employee.Age} years old.");
});
// 调用动态添加的方法
employee.DisplayInfo(); // 输出: Jane Smith is 28 years old.
// 将其作为字典来检查属性是否存在
var dict = (IDictionary<string, object>)employee;
if (dict.ContainsKey("Age"))
{
dict["Age"] = 29;
}
employee.DisplayInfo(); // 输出: Jane Smith is 29 years old.
优雅之处: 让你在 C# 中也能体验到像 JavaScript 或 Python 那样自由构建对象的快感，非常适合用于数据传输对象 (DTO)、视图模型 (View Model) 或测试存根 (Test Stub)。
5. dynamic 的性能考量与注意事项
没有免费的午餐，dynamic 的灵活性是以牺牲其他方面为代价的。
-
性能开销:
- 首次调用较慢: DLR 需要进行类型反射、成员查找和绑定，这比静态调用慢得多。
- 后续调用很快: 得益于 DLR 的调用点缓存，后续对同一类型的相同操作性能会大幅提升，但仍略逊于纯静态调用。
- 结论: 绝对不要在性能敏感的紧凑循环中使用
dynamic。对于大多数 I/O 密集型或用户交互操作，这点性能开销通常可以忽略不计。
-
失去编译时类型安全:
- 这是最大的缺点。拼写错误、方法签名变更等问题，编译器无法帮你发现。
dynamic d = "text"; d.ToUppr();这样的拼写错误，只有在代码运行到这一行时才会以RuntimeBinderException的形式爆炸。- 这将错误发现的环节从“开发时”推迟到了“运行时”，增加了调试成本和线上风险。
-
IntelliSense 和重构的缺失:
- Visual Studio 等 IDE 无法为
dynamic对象提供成员列表、参数信息等智能提示。你必须“盲打”，或者时刻查阅文档。 - 重构工具（如“重命名”）无法自动更新对
dynamic成员的调用。如果你重命名了Person类的FirstName属性为GivenName，所有dynamic person对象的person.FirstName调用都将成为运行时的地雷。
- Visual Studio 等 IDE 无法为
-
调试困难:
- 在调试器中监视
dynamic变量时，你可能无法像静态类型对象那样轻松地展开并查看其所有成员。你需要依赖“动态视图”等特定调试功能。
- 在调试器中监视
6. 总结：何时使用 dynamic？
dynamic 是一把双刃剑。请遵循以下准则：
-
优先使用静态类型: C# 是一门以静态类型为美的语言。在 95% 的情况下，强类型、编译时检查和工具支持带来的好处远远超过动态性。
-
在边界处使用
dynamic: 当你的 C# 代码需要与“外部世界”的动态实体交互时，dynamic是最佳选择。这些边界包括：- 与动态语言（Python, Ruby）的互操作。
- 处理非结构化或动态结构的数据（如 JSON、XML）。
- 简化 COM Interop。
- 在某些元编程或反射场景下，为了代码的可读性。
黄金法则: 当你发现为了让代码通过编译而不得不进行大量丑陋的类型转换和反射调用时，问问自己：“这里是不是 dynamic 的用武之地？”
dynamic 不是日常开发的常规武器，而是解决特定棘手问题的专家工具。理解其原理，明确其代价，你就能在需要它的时候，写出既灵活又优雅的代码。
ExpandoObject vs DynamicObject：深入对比
ExpandoObject 和 DynamicObject 都是 DLR 的重要组成部分，但它们服务于截然不同的目的。ExpandoObject 是一个“开箱即用”的动态对象，而 DynamicObject 是一个“DIY 工具包”，用于构建你自己的、具有高度自定义行为的动态类型。
核心区别一览
| 特性 | System.Dynamic.ExpandoObject |
System.Dynamic.DynamicObject |
|---|---|---|
| 类型 | sealed 类 |
abstract 基类 |
| 目的 | 即用型 的动态属性包 (Property Bag) | 用于 创建自定义 动态行为的 框架 |
| 用法 | 直接 new ExpandoObject() |
继承 它，并 重写 其 Try... 方法 |
| 实现方式 | 内部实现类似 IDictionary<string, object> |
你自己定义当成员被访问、调用或操作时发生什么 |
| 灵活性 | 有限。只能动态添加/移除属性和方法委托 | 极高。可以拦截几乎所有操作并自定义逻辑 |
| 比喻 | 一个 现成的魔法口袋，你可以随时往里放东西或拿东西 | 一套 制造魔法口袋的工具和蓝图，你可以决定口袋的材质、形状以及存取物品的规则 |
1. ExpandoObject：便捷的动态容器
正如前文所述，ExpandoObject 的设计目标是简单和方便。当你需要一个可以动态添加属性的对象时，它就是你的首选。
- *本质: 它是一个实现了
IDynamicMetaObjectProvider的密封类。它的行为非常像一个Dictionary<string, object>，但语法上允许你用.来访问成员。 - 优点: 零配置，上手即用。
- 缺点: 因为是
sealed的，你无法继承它来改变其核心行为。例如，你无法在访问一个 不存在的属性 时，自动从数据库或配置文件中加载它。访问不存在的属性只会导致RuntimeBinderException。
使用场景回顾:
- 解析和操作结构不固定的 JSON/XML。
- 创建用于数据绑定的简单视图模型 (View Models)。
- 在测试中创建模拟对象 (Mocks/Stubs)。
// ExpandoObject 的行为是固定的：它只是一个属性容器。
dynamic config = new ExpandoObject();
config.Timeout = 5000;
Console.WriteLine(config.Timeout); // 输出 5000
// Console.WriteLine(config.ConnectionString); // 运行时抛出 RuntimeBinderException，因为它不存在
2. DynamicObject：构建你自己的动态世界
DynamicObject 完全是另一回事。它是一个抽象基类，其本身几乎不做任何事情。它的价值在于 你通过继承它，并重写它的虚拟方法，来定义一个类型的动态行为。
当你对一个继承自 DynamicObject 的对象执行操作时（如 myDynamicObj.SomeProperty），DLR 不会直接操作对象，而是会调用你重写的对应 Try... 方法。这给了你一个 拦截点，让你完全控制接下来发生什么。
关键的 Try 方法
你需要重写这些方法来注入你自己的逻辑。如果你的方法能成功处理该操作，就返回 true；否则返回 false，让基类处理（通常意味着抛出异常）。
| 方法签名 | 触发操作 | 示例 |
|---|---|---|
TryGetMember(GetMemberBinder binder, out object result) |
读取属性 | var x = myDynamicObj.PropertyName; |
TrySetMember(SetMemberBinder binder, object value) |
设置属性 | myDynamicObj.PropertyName = 123; |
TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result) |
调用方法 | myDynamicObj.MethodName(arg1, arg2); |
TryBinaryOperation(BinaryOperationBinder binder, object arg, out object result) |
二元运算符 | var z = myDynamicObj + otherObj; |
TryUnaryOperation(UnaryOperationBinder binder, out object result) |
一元运算符 | var neg = -myDynamicObj; |
TryGetIndex(GetIndexBinder binder, object[] indexes, out object result) |
读取索引器 | var val = myDynamicObj[key]; |
TrySetIndex(SetIndexBinder binder, object[] indexes, object value) |
设置索引器 | myDynamicObj[key] = "value"; |
何时使用 DynamicObject？
当你想将动态成员访问映射到非标准的操作时。 换句话说，当 . 操作符的意义不再是“获取或设置一个字段”，而是：
- 查询数据库或 API。
- 导航 XML 或 JSON 树。
- 与底层字典、配置文件或其他数据结构交互。
- 实现动态代理或包装器。
- 创建领域特定语言 (DSL) 的流畅接口。
优雅的使用示例：创建一个动态 XML 包装器:
假设我们想用更简洁的语法来操作 XML，而不是使用繁琐的 XElement.Element("name").Value。我们希望可以像这样写：xml.Root.Person.Name。
ExpandoObject 无法做到这一点，但 DynamicObject 可以完美胜任。
using System.Dynamic;
using System.Xml.Linq;
using System.Collections.Generic;
using System;
// 1. 创建继承自 DynamicObject 的自定义类
public class DynamicXml : DynamicObject
{
private readonly XElement _element;
public DynamicXml(XElement element)
{
_element = element;
}
public DynamicXml(string xmlString)
{
_element = XElement.Parse(xmlString);
}
// 2. 重写 TryGetMember 来拦截属性读取操作
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
// binder.Name 就是我们正在访问的属性名 (例如, "Person")
XElement foundElement = _element.Element(binder.Name);
if (foundElement != null)
{
// 如果找到了子元素，就将它包装在另一个 DynamicXml 对象中返回
// 这使得链式调用成为可能 (e.g., xml.Root.Person)
result = new DynamicXml(foundElement);
return true;
}
// 如果找不到子元素，尝试查找同名的属性
XAttribute foundAttribute = _element.Attribute(binder.Name);
if (foundAttribute != null)
{
// 如果找到了属性，返回它的值
result = foundAttribute.Value;
return true;
}
// 如果访问的是 "Value" 属性，则返回当前元素的值
if (binder.Name == "Value")
{
result = _element.Value;
return true;
}
// 如果什么都没找到，操作失败
result = null;
return false;
}
// 3. (可选) 重写 TrySetMember 来支持写入
public override bool TrySetMember(SetMemberBinder binder, object value)
{
XElement foundElement = _element.Element(binder.Name);
if (foundElement != null)
{
foundElement.Value = value.ToString();
}
else
{
XAttribute foundAttribute = _element.Attribute(binder.Name);
if (foundAttribute != null)
{
foundAttribute.Value = value.ToString();
}
else
{
// 如果不存在，就创建一个新的子元素
_element.Add(new XElement(binder.Name, value));
}
}
return true; // 总是认为设置成功
}
}
// 4. 使用我们自定义的动态对象
class Program
{
static void Main()
{
string xmlString = @"
<Contact id='123'>
<Name>John Doe</Name>
<Address>
<City>New York</City>
<Zip>10001</Zip>
</Address>
<Phones>
<Phone type='Home'>111-111-1111</Phone>
<Phone type='Work'>222-222-2222</Phone>
</Phones>
</Contact>";
dynamic contact = new DynamicXml(xmlString);
// 使用优雅的语法读取数据
Console.WriteLine($"Name: {contact.Name.Value}"); // 输出: Name: John Doe
Console.WriteLine($"ID: {contact.id}"); // 输出: ID: 123 (访问属性)
Console.WriteLine($"City: {contact.Address.City.Value}"); // 输出: City: New York (链式访问)
// 动态修改数据
Console.WriteLine("\n--- Modifying Data ---");
contact.Address.City.Value = "Los Angeles";
contact.Email = "[email protected]"; // 动态添加新元素
Console.WriteLine($"New City: {contact.Address.City.Value}");
Console.WriteLine($"New Email: {contact.Email.Value}");
}
}
示例解析:
DynamicXml包装了一个XElement。- 当你写
contact.Name时，DLR 调用TryGetMember，其中binder.Name是"Name"。 - 我们的代码在
_element中查找名为 “Name” 的子元素。 - 找到后，我们创建了一个新的
DynamicXml对象来包装这个<Name>元素，并将其作为结果返回。 - 接下来你访问
.Value，这会再次触发TryGetMember，这次是在新的DynamicXml对象上，binder.Name是"Value"。我们的代码检测到这个特殊名称，并返回_element.Value。 - 这个过程完美地将动态属性访问 映射 到了 XML 树的导航上。
结论：该选择哪一个？
遵循这个简单的决策流程：
-
我是否只需要一个可以随时添加/删除属性和方法的对象，就像一个 JavaScript 对象一样？
- 是 → 使用
ExpandoObject。它是最简单、最直接的解决方案。
- 是 → 使用
-
我是否需要拦截属性访问/方法调用，并执行一些自定义的、非标准的逻辑（如查询数据库、调用 API、转换数据格式等）？
- 是 → 继承
DynamicObject，并重写相关的Try...方法。这是为了创建你自己的动态行为规则。
- 是 → 继承
简而言之，ExpandoObject 是 动态数据的容器，而 DynamicObject 是 动态行为的构建器。当你需要重新定义“点”（.）操作符的含义时，就是 DynamicObject 大显身手的时候。