将c#方法参数声明为`dynamic`会完全绕过编译器的静态类型检查，使调用方在编译阶段无法验证参数是否匹配或是否存在该方法，所有的类型安全和成员访问合法性判断都被推迟到运行时执行。
dynamic参数如何改变编译期的行为
当方法的参数被标记为dynamic时，编译器在处理对该方法的调用时，不再检查传入的实参类型是否与形参类型兼容。这意味着你可以传递任何类型的对象，甚至是一个不存在的变量名，代码都能顺利通过编译。这种机制的核心在于dynamic关键字告诉编译器放弃静态类型推断，转而使用动态绑定机制。在编译生成的IL代码中，对dynamic参数的处理会被转换为对Microsoft.CSharp.RuntimeBinder的调用，而不是普通的直接方法调用。因此，编译期原本应该抛出的“类型不匹配”或“方法不存在”等错误，在这里被静默忽略，程序得以生成可执行文件。
using System;
using System.Dynamic;
public class Calculator
{
// 参数声明为 dynamic
public void ProcessData(dynamic data)
{
// 这里不会在编译时报错，即使 data 可能没有 Value 属性
Console.WriteLine(data.Value);
}
}
class Program
{
static void Main()
{
var calc = new Calculator();
// 1. 正常调用：传入一个匿名对象，包含 Value 属性
calc.ProcessData(new { Value = 100 });
// 2. 潜在风险：传入一个不包含 Value 属性的整数
// 编译通过，但运行时会抛出 RuntimeBinderException
try
{
calc.ProcessData(42);
}
catch (RuntimeBinderException ex)
{
Console.WriteLine($"运行时错误: {ex.Message}");
}
// 3. 编译期检查失效示例
// 如果参数不是 dynamic，下面这行会编译报错
// calc.ProcessData(someUndefinedVariable);
}
}
与object参数在类型检查上的区别
如果不使用dynamic而是使用基类object作为参数类型，编译器的行为将截然不同。使用object时，编译器会确保传入的对象是object或其子类型，这是静态类型检查的一部分。然而，一旦进入方法体内部，由于变量类型为object，你无法直接访问该对象的特定属性或方法（如.Value），除非进行显式的类型转换或使用反射。相比之下，dynamic允许你在方法体内像操作已知类型一样直接访问成员，但这部分访问的检查被移到了运行时。简而言之，object保留了编译时的类型约束但牺牲了方法内的便捷性，而dynamic牺牲了编译时的安全性以换取方法内外的灵活调用。在实际开发中，如果确定传入对象的类型结构，通常建议使用泛型或具体类型，仅在处理动态数据结构（如JSON解析结果、COM互操作）时才考虑使用dynamic。
using System;
public class StaticChecker
{
// 参数声明为 object
public void ProcessWithObject(object data)
{
// 编译期：data 只能是 object 类型
// 以下代码编译报错，因为 object 没有 Value 属性
// Console.WriteLine(data.Value);
// 必须显式转换才能访问特定成员
if (data is dynamic dyn)
{
// 这里虽然用了 dynamic，但只是局部变量的转换
// 真正的动态检查发生在 dyn.Value 访问时
Console.WriteLine(dyn?.Value);
}
}
}
class Program
{
static void Main()
{
var checker = new StaticChecker();
// 传入匿名对象
checker.ProcessWithObject(new { Value = "Test" });
// 传入 null
checker.ProcessWithObject(null);
}
}
传入null值时的运行时表现
当向声明为dynamic参数的方法传入null值时，编译期依然不会报错，因为null可以隐式转换为任何引用类型，包括dynamic。然而，在运行时，CLR（公共语言运行时）需要确定null的具体类型以便进行动态分派。通常情况下，如果dynamic变量初始化为null，其运行时类型被视为null。当你尝试访问null的动态成员（例如null.SomeProperty）时，运行时 binder 会尝试解析该成员，但由于目标对象为空，通常会抛出RuntimeBinderException，提示“Cannot perform runtime binding on a null reference”。这与传统静态类型中访问空引用属性会抛出NullReferenceException不同，dynamic的错误信息更侧重于绑定失败而非简单的空指针。开发者在处理dynamic参数时，若不确定输入是否为空，应在方法内部显式检查if (data == null)，以避免不可预期的运行时异常。
