当方法参数声明为 dynamic 时，c# 编译器在编译阶段会跳过静态重载解析，将方法调用的绑定推迟到运行时由动态调度器（dlr）处理。这意味着在编译期，只要存在一个签名匹配且可访问的方法，代码就能通过编译；而具体调用哪一个重载版本，取决于运行时的实际对象类型和值。如果运行时找不到完全匹配的重载，则会抛出 runtimebinderexception。
编译期与运行时的选择差异是什么
这种机制的核心在于 dynamic 关键字改变了方法的查找时机。在普通静态类型中，编译器会根据参数的声明类型直接锁定唯一的重载版本；但在 dynamic 场景下，编译器仅进行最基础的语法检查，确保目标方法存在。真正的决策过程被移交给了运行时的 IDynamicMetaObjectProvider 或基于类型的启发式算法。例如，当传入一个 int 类型的变量给 dynamic 参数时，编译器不会去纠结该选 Process(int) 还是 Process(object)，而是生成一段中间代码，等待程序跑起来后，再根据变量的实际内存类型去决定调用路径。
using System;
class Program
{
static void Main()
{
// 定义不同签名的重载
Process(10); // 运行时输出: int
Process(3.14); // 运行时输出: double
Process("hello"); // 运行时输出: string
Process(null); // 运行时输出: object (因为 null 没有具体类型)
}
static void Process(dynamic value)
{
if (value is int i)
Console.WriteLine($"int: {i}");
else if (value is double d)
Console.WriteLine($"double: {d}");
else if (value is string s)
Console.WriteLine($"string: {s}");
else
Console.WriteLine($"object: {value}");
}
}
上述代码展示了典型的动态分派行为。尽管 Main 方法中的调用看起来像是在调用同一个方法，但每次执行的内部逻辑分支都不同。特别是 null 值的处理，由于 null 在 C# 中缺乏具体的运行时类型信息，DLR 通常会将其回退到基类 object 的处理逻辑，这解释了为什么 Process(null) 会进入 else 分支而非其他特定类型分支。
参数为空值或隐式转换时会发生什么
当 dynamic 参数接收 null 或者涉及隐式类型转换时，重载的选择逻辑会变得更为严格。对于 null，如前所述，它被视为 object 类型。但如果传入的是一个可以隐式转换为多种类型的值（例如 short 可以转为 int 也可以转为 long），运行时 DLR 会尝试寻找最精确的匹配。如果存在多个同样“精确”的重载，或者无法确定最佳匹配，编译器可能会报错或运行时报错，具体取决于是否实现了 IDynamicMetaObjectProvider。此外，如果传入的对象实现了 IDynamicMetaObjectProvider（如 ExpandoObject），则完全由该对象的 GetDynamicMemberOperations 等接口决定分发逻辑，此时传统的基于 CLR 类型的重载规则失效。
using System;
using System.Dynamic;
class Program
{
static void Main()
{
dynamic expando = new ExpandoObject();
// 这里会触发 RuntimeBinderException，除非 ExpandoObject
// 内部实现了相应的动态成员处理逻辑
try
{
Process(expando);
}
catch (Exception ex)
{
Console.WriteLine(ex.GetType().Name);
}
}
static void Process(dynamic value) { }
}
在这个例子中，ExpandoObject 是一个动态对象，它不遵循标准的 CLR 类型系统。当它作为 dynamic 参数传递时，CLR 不会像处理 int 那样直接查表，而是询问该对象“你支持哪些操作”。由于默认的 ExpandoObject 并没有预定义名为 Process 的动态方法重载解析逻辑，因此会在运行时抛出异常。这说明 dynamic 不仅仅是类型擦除，更是一种基于契约的动态协议交换。
基于传入具体输入类型时的最终决议结果
针对具体的输入类型，最终的决议结果遵循一套固定的优先级：首先是检查参数是否为 dynamic 类型本身，其次是检查是否实现了 IDynamicMetaObjectProvider，再次是检查 CLR 基础类型（如 int, string），最后是 fallback 到 object。如果我们在代码中显式传入一个 var 定义的 int，虽然变量是静态类型的，但一旦赋值给 dynamic 参数，其元数据中的类型信息就会被保留并用于运行时查找。若传入的是匿名类型，由于其类型名在编译期生成且不可见，通常只能匹配到 object 重载，除非该匿名类型恰好实现了特定的动态接口。这种机制确保了 dynamic 的灵活性，但也牺牲了编译期的安全性，开发者必须确保在运行时环境中，目标对象具备被正确分派的能力。
