为何明显的NullReferenceException不被视为编译时错误？

先给核心结论：C#编译器的静态分析逻辑不追踪变量的具体运行时值——哪怕你明明白白写了obj = null，编译器也不会把这个变量钉死在“永远是null”的状态里，这是出于对代码灵活性和通用场景的考虑。

具体原因拆解： #

• 变量是可变的：C#里的变量声明后随时能改值，编译器不会假设你写了obj = null之后就再也不会给它赋值。哪怕你当前示例里没改，但只要代码里存在后续赋值的可能（哪怕是分支里的），编译器就不能直接判定这个调用一定出错。要是把这种情况直接设为错误，很多合法的代码都过不了编译。
• null是合法的引用类型值：null本身就是所有引用类型的有效值，编译器没法区分“我故意赋值的null”和“后续会被修改的null”。强制把这种情况设为错误，会限制开发者处理边界场景的能力——比如你可能故意先把变量设为null，后续在运行时做null判断再处理。
• 编译期和运行时的职责划分：编译期管的是语法、类型是否合法，运行时才管具体值的状态（比如触发null引用异常）。把null调用方法直接判为错误，相当于把运行时的检查提前到编译期，这超出了编译器的设计目标，也会让代码失去灵活性。

关于你看到的反编译代码 #

你反编译后得到的((object) null).ToString()，只是编译器对obj.ToString()的常规编译结果——因为obj是object类型，编译器会按object实例调用方法的逻辑处理，哪怕它的值是null。但这并不代表编译器能“识别”这个调用一定会触发异常，因为编译器根本不追踪变量的具体值变化。

为什么给警告而不是错误？ #

编译器给警告是一种折中方案：它通过静态分析察觉到“这个变量大概率是null，调用方法有风险”，但又没法100%确定它一定是null，所以用警告提醒你，而不是直接阻止编译。如果你想要更严格的检查，可以启用nullable上下文（比如在代码开头加#nullable enable），让这种情况变成更严重的警告甚至直接报错，但这是可选的编译配置，不是默认行为。

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