为何重写的相等运算符未被调用？解析NullTester类的IL编译代码

先来看我们的场景：你定义了一个NullTester类，里面有三个判断对象是否为null的泛型方法，其中EqualsNull<T>用了o == null的写法，但编译后的IL代码里并没有调用T可能重写的==运算符，反而做了装箱和引用比较。我们来一步步拆解这个问题。

首先贴出原始的C#类代码：

public class NullTester { 
    public bool EqualsNull<T>(T o) where T : class { return o == null; } 
    public bool IsNull<T>(T o) where T : class { return o is null; } 
    public bool EqualsCall<T>(T o) where T : class { return object.Equals(o, null); } 
}

然后是EqualsNull<T>方法编译后的IL片段：

.method public hidebysig instance bool EqualsNull<class T> ( !!T o ) cil managed { 
    .maxstack 8 
    IL_0000: ldarg.1          // 把方法的参数o加载到评估栈顶
    IL_0001: box !!T          // 将泛型类型T的实例装箱为System.Object
    IL_0006: ldnull           // 把null值压入栈顶
    IL_0007: ceq              // 比较栈顶的两个值（装箱后的o和null）是否相等，返回布尔值
    IL_0009: ret              // 返回比较结果
}

关键解析：为什么装箱+ceq，而不是调用重写的==？ #

这里的核心原因是泛型方法编译时的不确定性：

• 虽然我们给T加了where T : class的约束，确保T是引用类型，但编译器在编译这个泛型方法的时候，根本不知道未来T会被实例化为哪个具体类型——它可能是一个没有重写==的类，也可能是一个重写了==的类（比如自定义了相等逻辑的业务类）。
• 为了保证o == null在泛型方法中的行为始终是判断引用是否为null，而不是执行T自定义的相等逻辑，编译器选择了最稳妥的方式：把T装箱为object，然后用IL的ceq指令做引用比较。
• ceq是IL层面的底层比较指令，对于引用类型来说，它直接比较两个对象的内存地址是否相同（或者是否为null），完全不会触发任何C#层面重写的==运算符或Equals方法。这就是为什么你重写的相等运算符从来不会被调用的原因。

对比另外两个方法的行为 #

为了更清晰，我们可以看看另外两个方法的逻辑：

• IsNull<T>（o is null）：这是C# 7.0引入的语法，专门用来检查引用是否为null。编译后的IL不需要装箱，直接做引用比较，同样不会调用自定义的相等逻辑，行为和== null完全一致，但实现更高效。
• EqualsCall<T>（object.Equals(o, null)）：这个方法的底层逻辑是先做引用比较o == null，如果是true直接返回true；如果不是，因为第二个参数是null，会直接返回false。所以最终效果也是判断引用是否为null，而且同样不会触发T重写的Equals方法（因为当第二个参数是null时，不会走到objA.Equals(objB)的步骤）。

总结 #

在泛型方法中使用== null判断引用类型是否为null时，编译器为了保证行为的一致性（无论T是否重写了==），会将T装箱为object，然后用IL的ceq指令进行底层引用比较，完全绕过了T可能重写的相等运算符。这就是为什么你的重写运算符从未被调用的原因。

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