var 在 AOT 下完全安全，因其仅为编译期类型推导语法糖，生成确定静态类型和完整 IL 类型信息，不触发反射或动态代码；真正风险来自 Bind() 等反射 API 或 dynamic/匿名类型/MakeGenericType 等运行时不可预测操作。
var 关键字本身与 AOT 完全无冲突，它只是编译期类型推导语法糖，不会生成任何运行时反射或动态代码。
为什么 var 在 AOT 下完全安全？
var 在 C# 中仅影响编译器行为：它让编译器根据右侧表达式推断出确定的静态类型，并在生成的 IL 中写入完整类型信息。最终产物和显式写出类型（如 string s = "abc"）完全等价。
- AOT 编译器（
ilc）看到的是已确定的类型，不是“未知类型” - 不触发
System.Reflection、不调用Activator.CreateInstance、不依赖MakeGenericType等动态机制 - 所有
var声明都会被静态解析，属于 AOT 友好范围内的“纯编译期行为”
容易误以为有冲突的典型场景
开发者常把 var 和真正危险的操作混在一起，误归因于 var。例如：
var config = new ConfigurationBuilder().AddJsonFile("appsettings.json").Build();
var settings = new Settings();
config.Bind(settings); // ✅ 安全 —— 但注意：.NET 8+ 推荐改用配置源生成器
这里真正需要注意的不是 var，而是 Bind() 方法本身 —— 它底层依赖反射。在 AOT 下，若未启用配置源生成器，Bind() 可能失败或被裁剪掉。
- ❌ 错误归因：
"var config = ...; config.Bind() 失败 → 是 var 的问题？" - ✅ 正确归因：
Bind()是反射驱动 API，AOT 默认禁用未声明的反射路径 - ✅ 解法：启用
EnableConfigurationBindingGenerator，让编译器生成无反射的绑定代码
真正要警惕的“伪 var”陷阱
当 var 推导出的是泛型闭包类型、匿名类型或 dynamic 时，风险才出现 —— 但这些根本不是 var 的锅，而是类型选择本身的问题：
-
var x = new { Name = "a" };→ 匿名类型在 AOT 下需额外保留元数据（否则序列化/反射失败） -
var y = (dynamic)"hello";→dynamic强制启用 DLR，AOT 不支持，编译直接报IL3050 -
var z = typeof(List).MakeGenericType(typeof(int));→MakeGenericType被标记为RequiresDynamicCodeAttribute，AOT 拒绝生成，报IL3050
这些错误信息里都带 IL3050，而 var 永远不会触发它。
AOT 兼容性问题永远出在「运行时行为不可静态预测」的地方，而不是语法糖。别被 var 这个名字迷惑——它连一个字节的运行时开销都不产生。真正该盯紧的，是那些藏在 var 后面、悄悄调用反射/emit/动态类型的调用链。
