C# 关键字 var —— 隐式类型推断声明变量

1. var 到底是什么？（隐式类型推断）

在 C# 中，var 的官方名称是隐式类型局部变量（Implicitly typed local variable）。

当使用 var 声明变量时，实际上是在对编译器说：“我懒得写出这个变量的具体类型了，请你看看等号右边是什么东西，自动帮我推断出类型，并把它固定下来。”

// 编译器看到右边是字符串，就会在底层把 var 替换成 string
var message = "Hello World";

// 编译器看到右边是整数，就会在底层把 var 替换成 int
var count = 100;

2. C# 的 var 最大的误区（它绝不是 JavaScript 的 var）

很多初学者觉得 var 意味着“动态类型”或者“随便什么类型都可以”，这是完全错误的。

C# 是一门强类型语言。var 只是一个让少打几个字的“语法糖”，它在编译时就已经被彻底确定为某一种具体的类型了，而且一旦确定，终生不能更改。

var age = 25; // 编译器推断出 age 是 int
// age = "Twenty Five"; // ❌ 报错！不能把字符串赋值给 int 类型的变量

如果真的想要一个可以随时改变类型的变量，在 C# 里应该用 dynamic 或 object，而不是 var。

3. 什么时候“必须”或“强烈建议”使用 var？

在现代 C# 开发中，通常推荐“只要不会降低代码可读性，就尽量用 var”。特别是以下几种场景：

场景 A：类型名字太长，且右侧已经很明显了

当在实例化一些复杂的泛型集合时，不使用 var 会导致代码严重重复（违反 DRY 原则）。

// ❌ 传统写法：类型名字写了两遍，又长又啰嗦
Dictionary<string, List<Customer>> dict = new Dictionary<string, List<Customer>>();

// ✅ C# 现代写法：清爽干净，一目了然
var dict = new Dictionary<string, List<Customer>>();

场景 B：处理 LINQ 查询结果

在使用 LINQ 时，返回的结果通常是 IEnumerable<T> 或 IQueryable<T>。使用 var 可以让专注于查询逻辑，而不是纠结返回的具体是什么集合接口。

var activeUsers = users.Where(u => u.IsActive).ToList();

场景 C：匿名类型（没有它不行）

如果想临时组装一组数据，又不想专门去写一个 class，就可以用匿名类型。这个时候必须用 var，因为这个临时生成的类型根本没有名字，没法显式写出来。

// 临时抽取数据组合
var tempInfo = new { Name = "Alice", Department = "IT" };
Console.WriteLine(tempInfo.Name);

4. 什么时候应该避免使用 var？

虽然 var 很好用，但如果滥用它，会导致代码变成了“盲盒”，让阅读代码的人（包括几个月后的自己）感到痛苦。

反面模式：右侧看不出类型的时候 如果调用的是一个普通方法，且方法名没有明确暗示返回值类型，用 var 就是灾难：

// ❌ 不好的写法：这到底是个什么东西？一个布尔值？一个状态码对象？一个字符串？
var result = ProcessData();

// ✅ 好的写法：明确告诉读者这是什么
bool isSuccess = ProcessData();

5. var 的局限性

• 只能用于局部变量：不能把 var 放在类的属性、字段，或者方法的参数、返回值里。它只能在方法内部（或者属性的 get/set 内部）使用。
• 必须赋初始值：因为编译器需要看等号右边的东西来推断类型。如果只写 var x;，编译器会直接报错：“请告诉我它是啥！”
• 不能赋值为 null：var obj = null; 是非法的，因为 null 本身没有类型，编译器无法推断。