var是编译期语法糖，编译时推断类型生成等效IL，非动态类型；适用于类型冗长、LINQ、泛型初始化等场景，但工厂方法返回object、数值精度敏感、需明确接口语义时应显式声明类型。
var 是编译期语法糖，不是运行时类型
用 var 声明的变量，编译器会在编译时根据右侧表达式推断出具体类型，并生成与显式声明完全等价的 IL。它不会让变量变成“动态类型”，也不会影响性能或类型安全。
常见误解是认为 var 类似于 JavaScript 的 var 或 C# 的 dynamic —— 实际上完全不是。下面这三行在编译后等效：
var s = "hello"; // 编译为 string s = "hello"; string s2 = "hello"; // 显式声明，效果一致 var list = new List<int>(); // 编译为 List<int> list = new List<int>();
如果右侧无法明确推断类型（比如 new [] { 1, "a" }），编译直接报错：Error CS0826: No best type found for implicitly-typed array。
该用 var 的典型场景
当类型名冗长、重复、或不增加可读性时，var 能显著减少噪音。重点不是“省字符”，而是避免把注意力拉到类型声明上，而偏离逻辑本身。
- 泛型类型初始化：用
var dict = new Dictionary<string, List<Task>>();比写两遍泛型参数更清晰 - LINQ 查询结果：如
var result = users.Where(u => u.Age > 18).Select(u => u.Name);，返回的是IEnumerable<string>，写全反而干扰阅读 - using 声明中配合工厂方法：
var stream = File.OpenRead("data.bin");，类型是FileStream，但调用方通常只关心它实现了Stream - 对象初始化器嵌套较深时：
var config = new AppSettings { Logging = new LoggingConfig { Level = LogLevel.Warning } };，左侧类型名太长且无信息增量
不该用 var 的关键情况
当省略类型名会让代码意图变模糊、或引入隐含风险时，必须显式写出类型。
- 返回类型不直观的工厂方法：
var x = JsonConvert.DeserializeObject("...");—— 实际返回object，极易引发后续NullReferenceException或装箱问题；应写成MyDto x = JsonConvert.DeserializeObject<MyDto>("..."); - 数值字面量默认类型易混淆：
var i = 42;推断为int，但var d = 3.14;推断为double（不是decimal！）；涉及精度敏感场景（如财务计算），必须显式写decimal d = 3.14m; - 接口 vs 具体实现需要明确语义：
var logger = new ConsoleLogger();把变量绑定到了具体类型，后续若想替换为FileLogger就得改声明；应写ILogger logger = new ConsoleLogger(); - 方法返回
object或基类但实际依赖子类行为：var obj = GetEntity();若GetEntity()返回object，后续调用obj.ToString()没问题，但obj.Id就会编译失败 —— 这种情况必须强制转型或显式声明目标类型
团队规范和 IDE 提示的现实影响
Visual Studio 和 Rider 默认支持将显式类型自动转为 var（Alt+Enter → “Use 'var' instead of explicit type”），但这个建议不总靠谱。它只看右侧能否推断，不管语义是否合理。
很多团队在 .editorconfig 中配置了 csharp_style_var_for_built_in_types 和 csharp_style_var_when_type_is_apparent，但要注意这些规则无法覆盖业务逻辑层的可读性判断。
真正容易被忽略的是：当你在重构一个方法、把局部变量提取为字段或属性时，var 会立刻失效 —— 字段/属性不允许用 var。所以过度依赖 var 可能导致后续提取操作失败或被迫重写类型声明。
