C#中实现类的值相等时需要保留null==null为true的语义

一、问题背景

在为类（class）实现值相等（Value Equality）时，开发者通常会：

• 实现 IEquatable<T>
• 重写 Equals(object)
• 重写 GetHashCode()
• 可能重载 == / != 运算符

在这一过程中，一个常见且关键的问题是：

当类被设计为"值相等"时，是否仍然需要保证 null == null 的结果为 true？

本文将从 语言规范、相等契约、运行时行为和正确实现模式 等角度，对该问题进行深入、系统的分析。

---

二、结论概述

结论明确且唯一：

是的。在 C# 中，无论一个类是否实现了值相等，都必须保留 null == null 为 true。

该行为并非实现细节或推荐实践，而是 C# 语言与 .NET 框架对"相等"语义的基础性约束。任何破坏这一约束的实现，都会导致类型行为违反规范并引发严重问题。

---

三、null 在 C# 中的语义定位

3.1 null 的语言含义

在 C# 中：

• null 表示 不存在的对象引用
• 它不是 System.Object 的实例
• 它不携带任何类型特定的值语义

因此，null 代表的是一种缺失状态（absence of instance），而不是一个可参与值比较的普通对象。

---

3.2 null 与相等判断的关系

在 C# 的设计中，null 并未被排除在相等关系之外。相反：

null 被视为一个合法的相等参与者，其相等语义由语言本身统一规定。

---

四、C# 相等语义的基础约束（Equality Contract）

4.1 相等关系的数学基础

C# 中的相等运算（== / Equals）被设计为满足**等价关系（Equivalence Relation）**的三大性质：

1. 自反性（Reflexivity）

   对任意 x，必须满足 x == x

2. 对称性（Symmetry）

   若 x == y，则 y == x

3. 传递性（Transitivity）

   若 x == y 且 y == z，则 x == z

这些性质并非可选，而是 整个 .NET 类型系统和算法正确性的前提。

---

4.2 null == null 与自反性

若令：

null == null == false

则自反性立即被破坏：

object x = null;
x == x  // false

这将导致：

• 相等不再是等价关系
• 语言和框架中大量隐含假设失效
• 通用算法无法正常工作

因此，从契约角度：

null == null 必须为 true，否则相等语义在逻辑上不成立。

---

五、Equals 与 == 的框架级一致性要求

5.1 object.Equals 的规范行为

.NET 明确规定：

object.Equals(null, null) == true
object.Equals(null, x)    == false

这一行为是所有类型相等语义的基础入口。

---

5.2 实现值相等时的一致性要求

当一个类实现值相等时，必须满足以下一致性原则：

对任意 a、b：
a == b 与 object.Equals(a, b) 在语义上必须一致

如果重载 == 却破坏了 null == null：

object.Equals(null, null) // true
null == null              // false

则相等语义出现分裂，这是框架层面不允许的。

---

六、值相等实现的"职责边界"

6.1 开发者可以定义的内容

在 C# 中，当实现类的值相等时，开发者仅被允许定义：

两个"非 null 实例"在何种条件下被视为相等

通常体现在：

bool Equals(T other)
{
    // 定义非 null 实例之间的值相等逻辑
}

---

6.2 开发者不可修改的前提

以下语义 不属于开发者的定义范围：

• null 的含义
• null == null 的结果
• object.Equals(null, null) 的行为
• 相等关系必须满足等价关系约束

试图通过重载 == 改变这些前提，属于违反语言与框架契约的行为。

---

七、错误实现示例及其后果

7.1 错误示例

public static bool operator ==(Person left, Person right)
{
    if (left is null || right is null)
        return false; // 错误：破坏 null == null
    return left.Equals(right);
}

---

7.2 直接后果

1. 违反自反性

Person p = null;
p == p // false

2. == 与 Equals 语义不一致

3. 集合与算法行为不可预测

• HashSet<T>
• Dictionary<TKey, TValue>
• LINQ 操作
• 通用比较算法

这些问题往往隐蔽且难以调试。

---

八、正确且规范的实现方式

8.1 推荐的 == / != 实现

public static bool operator ==(Person left, Person right)
{
    return object.Equals(left, right);
}

public static bool operator !=(Person left, Person right)
{
    return !object.Equals(left, right);
}

8.2 该实现保证的行为

场景	结果
null == null	true
null == 非 null	false
非 null == null	false
非 null == 非 null	委托给值相等逻辑

---

九、与 record 类型的对比说明

在 C# 9.0 及以后，record 类型：

• 自动实现值相等
• 自动保证 null 语义正确
• 自动满足相等契约

这进一步说明：

保留 null == null == true 是值相等设计的前提条件，而不是实现细节。

---

十、结论

在 C# 中实现类的值相等时，必须且无条件地保留 null == null 为 true。

这是因为：

1. null 的相等语义由语言统一规定
2. 相等必须满足等价关系的基本数学约束
3. == 与 Equals 必须保持一致
4. .NET 框架和集合类型依赖这一前提运行

值相等的实现，是在既定相等语义之内扩展"非 null 对象如何比较"，而不是重新定义相等本身。

这既是语言规范的要求，也是健壮、可维护代码的必要条件。