为何Double.CompareTo()方法内部使用"=="运算符进行比较？

每个C#开发者都清楚，不应使用==运算符比较实数。那么为何.NET框架中的Double.CompareTo方法在检查相等性时会采用如下实现？

public int CompareTo(double value)
{
    if (m_value < value) return -1;
    if (m_value > value) return 1;
    if (m_value == value) return 0; // <= here
    
    // At least one of the values is NaN.
    if (IsNaN(m_value))
        return IsNaN(value) ? 0 : -1;
    else
        return 1;
}

核心原因：CompareTo的语义和普通相等判断完全不同 #

• 前置判断已过滤精度差异的情况
  代码先通过<和>判断了两个数的大小关系，如果能走到==这一步，说明两个数既不小于也不大于对方。对于正常的非NaN浮点数来说，这种情况下必然是严格相等的——精度误差只会导致两个数出现大小差异，早就在前两个条件分支里被处理了，根本到不了==判断这一步。

• 专门处理NaN的特殊规则
  浮点数的NaN是个特殊值，它和任何值（包括自己）用==比较都会返回false。所以当==判断不成立时，就意味着至少有一个值是NaN，这时候进入专门的分支处理：两个NaN视为排序相等，单个NaN则排在普通浮点数的后面，这符合.NET对浮点数排序的规范。

• 遵循IComparable接口的契约
  CompareTo是IComparable接口的实现方法，它的核心职责是提供严格的排序逻辑，而不是业务场景中的“近似相等”判断。排序需要明确每个元素的相对位置，必须严格遵循浮点数的数值规则，所以用==来区分正常相等和NaN的特殊情况是完全合理的。

日常不推荐用==比较实数的原因 #

我们日常开发中比较实数，往往是想判断“两个数在业务场景下是否足够接近”，比如计算结果和预期值的误差在可接受范围内。但CompareTo的目标是数值排序，不需要考虑业务上的近似需求，只需要严格按照浮点数的数值特性来确定顺序，所以两者的使用场景完全不同。

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