dynamic是为com互操作、动态json解析和expandoobject等“结构不可知”场景设计的运行时绑定机制，非权宜之计；它延迟所有成员访问至运行时，放弃编译期安全但保留实际类型信息。
直接说结论：dynamic 不是用来“避开类型检查”的权宜之计，而是为特定互操作场景设计的运行时绑定机制——它不取消类型，只是把绑定时机从编译期挪到运行期。滥用它等于主动放弃编译器最基础的安全网。
什么时候该用 dynamic？看这三类真实场景
真正需要 dynamic 的地方，几乎都绕不开“结构不可知”或“契约未固化”：
- 调用 COM 组件（如
Microsoft.Office.Interop.Excel.Application），其对象模型在编译时没有强类型定义，IDL 导入后仍大量使用object，用dynamic可写app.Workbooks.Add()而非反射式app.GetType().InvokeMember("Workbooks", ...) - 解析不确定结构的 JSON：比如
var data = JsonConvert.DeserializeObject<dynamic>(json)</dynamic>，后续可直接写data.users[0].name，无需提前定义UserDto类 - 桥接动态对象，如
ExpandoObject或 IronPython 返回的对象，它们的成员名和数量在运行时才确定，dynamic是唯一能自然点号访问的方式
dynamic 和 var、object 的关键区别在哪？
这不是语义偏好问题，而是绑定行为的根本差异：
-
var是编译期推导，推导结果是具体类型（如int），之后所有操作都走静态绑定；dynamic声明后，**所有成员访问、方法调用、运算符重载全部延迟到运行时解析** -
object不能直接点属性或调用方法，必须显式转换或反射；dynamic允许d.Name、d + 1、d["key"]，但这些操作失败会抛RuntimeBinderException，不是NullReferenceException或InvalidCastException - 赋值给
dynamic的变量，其类型信息不会丢失：比如dynamic d = "abc"; Console.WriteLine(d.GetType())输出System.String，不是dynamic
为什么 dynamic 性能差、IDE 提示失效、还容易漏掉 bug？
因为编译器对 dynamic 表达式只做语法检查，不查语义：
- 智能提示（IntelliSense）无法预知运行时类型，所以
d.后面不显示任何成员 - 拼写错误（如把
Length写成Lenght）不会报错，直到运行时触发RuntimeBinderException - 每次成员访问都要走 DLR（Dynamic Language Runtime）的绑定流程：查找类型、缓存 binder、验证可访问性——比直接调用慢 5–10 倍（实测常见场景）
- 泛型约束无法作用于
dynamic，例如void Process<t>(T item) where T : ICloneable</t>不能接受dynamic参数，因为dynamic不是运行时类型，而是一个编译指示符
最常被忽略的一点：你写的 dynamic 代码，只要没被单元测试覆盖到具体分支，就等于裸奔——编译器不会帮你挡任何错，连参数个数不对这种低级错误都放行。它不是“灵活”，是把校验责任完全移交给了你和你的测试用例。
