dynamic 类型的核心用途是：绕过编译时类型检查，把成员访问、方法调用、运算符解析等全部推迟到运行时决定——它不是“弱类型”，而是“晚绑定”。
什么时候必须用 dynamic
？
不是“能用就用”，而是某些场景下不用它，代码会极其繁琐甚至无法实现：
调用 COM 对象（如 Excel / Word 互操作）：Microsoft.Office.Interop.Excel.Application的很多属性/方法在编译时无法静态推导，用
dynamic可直接写
xlApp.Workbooks.Add()，否则要写一堆
Type.InvokeMember反射调用 解析结构不确定的 JSON：比如
JsonConvert.DeserializeObject<object></object>返回的是
object，你得反复
as JObject或
JToken.ToObject<t>()</t>；而用
dynamic data = JsonConvert.DeserializeObject(json)后，可直接写
data.Name、
data.Address.City，像访问原生对象一样 与动态语言（IronPython、JavaScript via ClearScript）交互：对方返回的对象没有 .NET 类型定义，
dynamic是唯一能自然桥接的类型
dynamic
和 var
、object
的区别到底在哪？
这是最容易混淆也最常踩坑的地方：
var是编译器“猜类型”，本质仍是静态类型：
var x = "abc"→ 编译后就是
string x，再赋值
x = 42直接报错
object是所有类型的基类，但访问成员必须显式转换：
object o = "hello"; int len = ((string)o).Length—— 写起来啰嗦，且转换失败会抛
InvalidCastException
dynamic不做任何编译检查，所有成员解析全靠 DLR（Dynamic Language Runtime）在运行时完成：
dynamic d = "hello"; int len = d.Length✅；
d.SomeMissingMethod()❌ —— 运行时报
RuntimeBinderException，不是编译错误
为什么用了 dynamic
后性能变慢、IDE 没提示？
因为它的底层依赖反射 + 缓存绑定逻辑，每次属性访问或方法调用都要走 DLR 的绑定流程：
首次访问obj.Name会触发完整绑定（查找类型、成员、重载解析），耗时明显；后续同路径访问会缓存，但缓存键含类型信息，换类型就失效 Visual Studio 的智能提示（IntelliSense）对
dynamic只显示“此操作将在运行时解析”，不提供补全 —— 这不是 bug，是设计使然 高频循环中用
dynamic访问属性（比如解析万条 JSON 记录）比强类型慢 3–5 倍，建议只在“一次解析、多次读取”或“低频交互”场景使用
怎么安全地把 dynamic
转成真实类型？
不能靠强制转型（
(int)d会抛异常如果
d实际是 string），推荐以下方式：
dynamic d = 42;
// ✅ 安全转 int（失败返回 0）
int i = d as int? ?? 0;
// ✅ 安全转 string（失败返回 null）
string s = d as string;
// ✅ 检查是否存在某个属性（避免 RuntimeBinderException）
if (d is IDictionary<string, object> dict && dict.ContainsKey("Name"))
{
string name = dict["Name"] as string;
}
更稳妥的做法是：只在边界处（如 API 输入、配置加载）用
dynamic快速解包，拿到数据后立刻映射到具体 DTO 或
ExpandoObject，后续逻辑全部走强类型。
真正难的不是怎么写
dynamic，而是判断“此刻是否真的需要它”——多数时候，一个明确的类 +
JsonSerializerOptions.PropertyNamingPolicy就比满屏
dynamic更可靠、更快、更容易调试。
