object、dynamic、var：三种“万能类型”的本质区别

一、引言

在 C# 日常开发中，我们经常会遇到三种看起来非常灵活的写法：

object obj = 10;
dynamic dyn = 10;
var num = 10;

一眼看去，它们似乎都能“接收任意类型”，因此不少人会下意识地把它们当成同一种能力的不同马甲——反正都能装东西，用什么不一样？

但事实并非如此。这三者分别工作在不同的运行时层级上：

• object 扎根于 CLR 类型系统，是真正的“万能基类”；
• dynamic 依赖 DLR（Dynamic Language Runtime）的动态绑定机制，把类型检查推迟到运行时；
• var 则只是 C# 编译器提供的类型推断语法糖，根本不是一个真正的“类型”。

它们虽然都能写出“万能”的假象，但其工作层级、运行机制、性能开销和工程价值完全不同。本文将从编译器、CLR、DLR 乃至 IL 的角度，深入拆解这三种机制的本质区别，帮你真正理解那句老话背后的事实：万能是有代价的。

二、object：CLR 的通用容器

1. object 是所有类型的根类型

在 .NET 体系中，System.Object 位于所有类型继承树的最顶端。无论是值类型还是引用类型，最终都继承自 System.Object。因此，从类型系统的角度看，object 可以承载任何值：

object obj1 = "Hello";
object obj2 = new User();
object obj3 = 42;

这三行代码全都合法，因为 string、User 和 int 最终都可追溯到 System.Object。

2. 引用类型赋值不会发生装箱

很多开发者一看到 object obj = "Hello"; 就本能地认为：这里一定发生了装箱。实际上，装箱只与值类型有关，string 本身就是引用类型。

string str = "Hello";
object obj = str;

在这一赋值过程中，CLR 做的仅仅是一次引用转换（将 string 引用赋给 object 类型的变量），完全不会在托管堆上创建额外的对象。你可以通过查看 IL 来证实——这里只有 stloc / ldloc，不会出现 box 指令。

3. 值类型赋值会发生装箱

真正发生装箱的，是把值类型塞进 object 的时候：

object obj = 10; // int 是值类型

此时编译器会生成类似以下的 IL：

ldc.i4.s 10
box System.Int32
stloc.0

CLR 会按照固定步骤执行装箱：

这一过程就是装箱（Boxing），它悄悄地引入了堆分配和复制开销。

装箱前后的内存布局变化可以描述为：装箱前，值类型变量 n = 10 直接存储在栈上，仅占用存放整数值的空间。装箱发生时，CLR 在托管堆上分配一块内存，构建一个完整的对象：该对象由同步块索引（SyncBlock）、类型描述符（TypeDesc）和实际的数值 10 三部分组成。随后，一个 object 类型的变量（如 obj）被置于栈上，其内容是指向堆中该对象的引用。这样，原来的值类型数据就从栈复制到了堆，并多出了对象头部开销，栈上只留下一个引用指针。

4. 拆箱过程

要取出原始值，必须强制转换：

object obj = 10;
int num = (int)obj;

对应的 IL 中会出现：

unbox.any System.Int32

这就是拆箱（Unboxing）。拆箱同样不是免费的：运行时需要先检查对象是否真的是目标值类型，然后复制数据回栈上。类型不匹配时，会抛出 InvalidCastException。

5. 性能影响

频繁装箱不仅会产生大量临时堆对象，增加 GC 压力，还会因数据复制和类型检查消耗 CPU。一个典型的反面教材是旧时代的 ArrayList：

ArrayList list = new ArrayList();
for (int i = 0; i < 1000000; i++)
{
list.Add(i); // 每次循环装箱一次
}

这里的每一次 Add 都会将 int 装箱为 object，性能影响非常可观。正因如此，才有了泛型集合 List<T> 的诞生。

当然，这并不是说 object 就该被抛弃。在反射、通用容器、统一抽象边界等场景中，object 依然是合理甚至唯一的选择。关键就在于：弄清楚什么时候会出现装箱，并避免在高频路径上触发它。

三、var：编译器的语法糖

1. var 不是类型

有些人把 var 当作一种“模糊的动态类型”，就像 JavaScript 中的 var 一样。但这完全是一种误解。

var 根本不是 CLR 中的类型，它只是 C# 编译器提供的类型推断语法。 你无法在 IL 中找到任何一个叫 var 的类型标识。

2. 编译时完成类型推断

编译器在分析代码时，会从右侧表达式直接推导出变量的真实类型：

var num = 10;

编译器会看到 10 是 int 字面量，于是这行代码在编译后完全等价于：

int num = 10;

一切推断都在编译阶段完成，运行时对此一无所知。

3. IL 验证

写一个简单方法：

var str = "Hello";
Console.WriteLine(str);

查看编译后的 IL，局部变量声明部分为：

.locals init (
[0] string str
)

var 已经消失得干干净净，留下的只有确切类型 string。这也意味着使用 var 声明的变量具有和显式类型完全相同的性能——零额外开销。

4. var 为什么不是动态类型

这是初学者最容易踏入的误区。看下面这段代码：

var num = 10;
num = 20; // 完全合法
num = "Hello"; // 编译错误：Cannot implicitly convert type 'string' to 'int'

编译器会毫不犹豫地报错，因为 var 仅仅帮你“猜”出了变量的类型，它并不会让变量变成能接纳一切类型的容器。num 仍然是 int，一旦推断完成，它的类型就固定了，与显式写出 int num = 10; 没有任何区别。

因此，var 只是一种省略类型名称的语法，它没有改变 C# 的强类型本质，更不是动态类型系统的一部分。

5. 为什么成员变量不能使用 var

局部变量可以用 var，但类成员却不行：

// 合法
var num = 10;

// 非法
class Demo
{
var age = 18; // 编译错误
}

原因在于：类的字段定义必须在类型元数据中明确记录其类型，而 var 的类型推断依赖于上下文，无法提升到类型定义层面。因此 C# 设计时就把 var 限制在了局部变量范围内。

6. 使用建议

var 最适用的场景包括：

• 长到令人窒息的泛型声明：var dict = new Dictionary<string, List<int>>();
• LINQ 查询和匿名类型：var result = users.Where(x => x.Age > 18).Select(x => new { x.Name, x.Age });
• 明显的构造函数调用：var user = new User();

在这些场景下，var 既让代码保持强类型和编译期检查，又减少了视觉噪音，可以说是“鱼和熊掌兼得”的典型。

四、dynamic：DLR 的运行时魔术

1. dynamic 的本质

许多人以为 dynamic 是一种动态类型，类似 Python 中的变量。但真相是：

在 CLR 看来，dynamic 的本质仍然是 System.Object。

编译器会在元数据中记录 DynamicAttribute 信息（尤其多见于方法签名、参数、返回值及字段），并生成一套基于 CallSite 和 Binder 的动态绑定代码。真正实现运行时成员解析的并非什么“动态类型”，而是这套由编译器注入的 DLR 基础设施。

2. DLR 的工作机制

看一段代码：

dynamic d = "Hello";
Console.WriteLine(d.ToUpper());

编译器看到 d 是 dynamic 后，会直接跳过对 ToUpper 的静态类型检查。取而代之的是，它生成一些辅助代码，利用 CallSite、Binder 和 DynamicMetaObject 等 DLR 基础设施，在运行时执行真正的成员绑定。

具体步骤大致为：

所有这一切都发生在运行时，而不是编译时。

3. ExpandoObject 示例

dynamic 与 ExpandoObject 结合，可以实现属性在运行时的动态扩展，类似于 JavaScript 对象：

dynamic d = new ExpandoObject();
d.Name = "Test";
Console.WriteLine(d.Name); // 输出 Test

这种能力完全建立在 DLR 的运行时解析之上，静态类型系统对此毫无感知。

4. 运行时异常

因为编译阶段放弃了类型检查，错误的成员调用会被推迟到运行时：

dynamic d = "Hello";
d.Run(); // string 没有 Run 方法

这段代码编译顺风顺水，但在运行时会直接抛出：Microsoft.CSharp.RuntimeBinder.RuntimeBinderException

这也就是 dynamic 最大的“坑”：它将编译时安全网搬到了运行时，把发现错误的时间点大大后移了。

五、为什么 dynamic 比静态绑定更慢？

很多开发者知道 dynamic 慢，但不清楚到底慢在哪里。我们用一组清晰的对比来说明。

静态绑定

如果你用显式类型的局部变量调用方法：

string str = "Hello";
str.ToUpper(); // 静态绑定

编译器在生成 IL 时，就已经完全确定将调用 string.ToUpper() 方法，直接发出 call 或 callvirt 指令，调用路径短平快，毫无额外运行时开销。

dynamic 的动态绑定

同样的调用换成 dynamic：

dynamic d = "Hello";
d.ToUpper();

DLR 需要额外做一系列工作：

首次调用的成本显著高于静态绑定，即便是后续缓存命中的调用，也无法回避动态分发基础设施的固有开销。

CallSite 缓存机制

需要澄清的是，dynamic 并不等同于每次都进行反射。DLR 会为每个调用点（CallSite）维护一个缓存，其缓存键由调用位置与实际参数类型共同组成。也就是说，只有当在同一个代码位置，且运行时对象的类型与缓存的类型完全相同时，才会复用绑定规则。

看下面的例子：

dynamic d = "Hello";
Console.WriteLine(d.Length); // 首次绑定 string，缓存一条规则

d = 10;
Console.WriteLine(d.ToString()); // 实际类型变为 int，缓存未命中，重新绑定并生成新规则

当 d 重新赋值为 int 后，同一调用点（两次成员访问均发生在此代码位置）遇到了新的实际类型，DLR 会再次经历完整的绑定流程，生成并缓存一条专为 int 服务的新规则。这意味着：一旦 dynamic 变量在不同类型间频繁切换，缓存的命中率就会下降，性能优势随之削弱。

async 场景下的额外风险

当 dynamic 遇上 async/await，风险会被进一步放大：

dynamic result = await GetDataAsync();
result.Process(); // 编译时完全沉默，运行时才能知道是否有 Process 方法

await 操作会解开任务并返回实际对象，但其返回类型在编译期往往只能被推断为 Task 或 Task<object>。一旦后续代码通过 dynamic 调用成员，编译器便彻底“放手”，所有错误都将被推迟到运行时——而且可能发生在远离调用点的地方，极大增加了调试难度。因此，在异步流程中使用 dynamic 要格外谨慎，建议在获得结果后尽快将其转换为具体的强类型。

六、dynamic 与反射的对比

很多开发者在了解 dynamic 之后会问：“它和反射有什么区别？看起来都能在运行时调用成员。” 这里我们做一个清晰的对比。

反射调用示例：

object user = GetUser();
MethodInfo method = user.GetType().GetMethod("Run");
method.Invoke(user, null);

dynamic 调用示例：

dynamic user = GetUser();
user.Run();

两者都能绕过编译时类型检查，但底层机制和工程体验差异巨大：

一句话总结：dynamic 可以看作构建在 DLR 之上的高级动态调用语法，它并非反射的简单语法糖。在需要缓存加速和简洁语法的动态调用场景中，dynamic 更具优势；但如果需要对类型成员进行更细粒度的操控（如遍历方法、特性等），反射仍然是不可或缺的工具。

七、编译器与 IL 的视角

如果用一个表格来总结三种机制在底层的行为：

更形象一些，可以按照工作层级自上而下划分为：

text

var 编译器层（仅存在于源码，编译后消失）
object CLR 层（实实在在的基类，直接参与运行时）
dynamic DLR 层（构建在 CLR 之上的一整套动态机制）

这是理解三者区别最重要的认知框架：它们不是同一层级的不同选项，而是位于完全不同的抽象层次上。

八、工程化影响：安全性与维护成本

技术细节最终要落实到工程实践上。下面从几个关键维度对比三者在实际项目中的表现：

特别需要留意的是 dynamic 对重构能力的影响。举例来说：

dynamic user = GetUser();
var name = user.Name;

IDE 无法从静态信息中准确分析 user 的成员。当你对属性名称执行 Rename、Find References 或进行静态代码检查时，这些操作都可能失效或遗漏。因此，在大型项目中，通常会严格限制 dynamic 的使用范围——仅在 COM 互操作、动态 JSON 处理等无可替代的场景中使用。

九、结论与最佳实践

从安全、性能和可维护性的综合角度出发，可以总结出一条更为严谨的默认优先级：

强类型 > var > object > dynamic
（在满足业务需求的前提下）

• 强类型（显式类型与 var 的准确推断）：是 C# 的根本优势，提供完整的编译期保障和最佳性能。
• var：强类型的简写形式，零开销，不损失任何安全性，适用于局部变量、LINQ 和匿名类型。
• object：作为统一抽象容器，适合于反射、框架边界或需要承载任意类型的地方。小心值类型装箱。
• dynamic：是最后手段，仅在 COM 互操作、动态 JSON 处理、与动态语言集成等确有必要时使用。引入它意味着放弃编译期检查，并承担运行时绑定和潜在异常的风险。

最终，我想用一句话凝练三者的本质：

object 是 CLR 的万能容器，dynamic 是 DLR 的运行时魔术，var 则只是编译器递给你的语法糖。

理解它们所在的层级差异，比记住它们的语法规则重要得多。下次当你写下这三个词时，不妨在心里过一次那张“编译器 → CLR → DLR”的层级图，相信你会做出更合理的选择。