为何C#中CS0165是错误而非警告？未赋值局部变量疑问

问题背景 #

我通常会在声明引用类型变量时为其赋值null。如果不这么做，在下面的示例代码中，调用Console.WriteLine(p)时会触发CS0165错误（未赋值的局部变量被使用）。我想知道：

1. 为什么这是错误而非警告？
2. 给变量赋值null只是消除了编译错误，但调用p.MyMethod或访问p.MyField仍会在运行时引发空引用异常，那为什么将其设为错误是更优的设计选择？

示例代码 #

static void Main(string[] args)
{
    Person p;
    try
    {
        p = new Person("A");
    }
    catch
    {
    }
    Console.WriteLine(p);
}

编译报错 #

Error CS0165 Use of unassigned local variable 'p'

解答 #

为什么是错误而非警告？ #

C#编译器的核心目标之一是在编译阶段尽可能捕获明确的逻辑错误，未赋值的局部变量使用属于"确定会导致不可预期行为"的场景。局部变量不会像类成员那样被默认初始化，若在未赋值的情况下使用它，变量的内存状态是不确定的——对于引用类型来说，它可能指向一块随机的内存地址，这比null更危险：不仅会引发空引用异常，甚至可能破坏内存数据、导致程序崩溃或出现难以调试的诡异行为。

编译器通过静态分析可以明确判断出p存在未被赋值就使用的路径（比如示例中try块抛出异常时，p完全没被初始化），这种明确的错误没有理由降级为警告——警告通常是"可能有问题但不确定"的场景，而这里是"必然存在风险"的确定错误。

为什么设为错误是更优设计？ #

虽然赋值null能绕过编译错误，但这其实是在掩盖问题，而非解决问题。编译器强制报错的目的，是倒逼开发者明确变量的初始化逻辑，而不是用null蒙混过关：

• 它提醒你必须处理所有代码路径下的变量初始化：比如示例中，你应该考虑try块失败时p的取值——要么给p一个默认实例，要么在catch块中赋值，要么直接在声明时就赋予合理的初始值，而不是随便丢个null。
• 空引用异常是运行时错误，只有程序跑起来才会暴露，而编译错误能在开发阶段就把问题扼杀在摇篮里。相比之下，提前发现问题的成本远低于事后调试空引用异常的成本。
• 强制要求变量初始化，也能让代码逻辑更清晰：其他开发者一眼就能看出变量的取值来源，避免因"不确定变量是否已赋值"带来的阅读和维护成本。

内容的提问来源于stack exchange，提问作者H2ONaCl