C++三路比较运算符 <=>：不是语法糖，是类型契约的重新定义

刚接触 C++20 的 <=> 运算符时，我下意识把它当成了“自动写 == 和 < 的快捷键”——直到在写一个自定义时间区间类时，它默默把 operator< 的逻辑搞反了，测试用例全绿，业务却悄悄跑偏。那一刻才明白：<=> 不是省事工具，而是强制你回答一个问题：你的类型，究竟该怎么被“有序地比较”？

三路比较运算符（也叫“太空船运算符”，spaceship operator）表面看只是个符号：a <=> b 返回一个 std::strong_ordering、std::weak_ordering 或 std::partial_ordering 类型的对象。但它的真正分量，在于它把比较语义从“函数集合”收束为“单一契约”。

过去我们写 operator<、operator==、operator<=……各自独立实现，靠人肉保证逻辑自洽。结果呢？有人忘了 a <= b 应该等价于 !(b < a)；有人让 == 比较值而 < 比较地址；更常见的是——为了支持容器排序，只重载 <，却忘了 == 仍走默认逐成员比较，导致 set.find() 找不到明明“相等”的对象。这些不是疏忽，是设计权分散带来的必然熵增。

<=> 的破局点，就在这里：它要求你一次性定义“全序关系的核心判据”，其余所有比较操作（==, !=, <, <=, >, >=）由编译器按标准数学规则推导生成。
不是“帮你生成代码”，而是“用你的一个答案，约束全部行为”。

比如一个简单的 Point2D：

struct Point2D {
    int x, y;
    auto operator<=>(const Point2D& other) const = default;
};

default 不是偷懒——它触发编译器按成员顺序逐个调用 <=>（先比 x，x 相等再比 y），并严格保证：
✅ a == b 当且仅当 a <=> b == 0
✅ a < b 当且仅当 a <=> b < 0
✅ a > b 当且仅当 a <=> b > 0

这个“当且仅当”是铁律。你无法绕过它加特例，也不能让 == 和 <=> 语义打架——编译器会在你试图同时定义 operator== 和 operator<=> 时直接报错（除非显式 = delete 其中一个）。

那什么时候不能 default？当你需要非字典序逻辑时。比如一个表示“任务优先级”的枚举：

enum class Priority { LOW, MEDIUM, HIGH };

default 会按底层整数值比较（LOW=0, MEDIUM=1, HIGH=2），这没问题。但若你定义了一个 Task 类，想按“剩余截止时间 + 优先级”综合排序，就得手写：

struct Task {
    std::chrono::system_clock::time_point deadline;
    Priority priority;

    auto operator<=>(const Task& other) const {
        // 先比截止时间（越早越紧急）
        if (auto cmp = deadline <=> other.deadline; cmp != 0)
            return cmp;
        // 时间相同时，高优先级胜出
        return priority <=> other.priority;
    }
};

注意这里用了 if 分支 + return，而非 ?: ——因为 priority <=> other.priority 返回的是 std::strong_ordering，而 deadline <=> other.deadline 也是同类型，它们可直接比较是否为 0，无需转换或 cast。这是 <=> 类型系统的关键细节：三个 ordering 类型都重载了 == 和 !=，但 > < 等不支持（避免歧义），你只能判断是否等于零。

说到返回类型选择：strong_ordering 要求所有值可比且无等价类（如整数）；weak_ordering 允许不同值“等价”（如忽略大小写的字符串比较）；partial_ordering 则容忍“不可比”（如浮点数里的 NaN）。选错类型，编译器会拒绝生成某些比较操作。比如用 partial_ordering 返回 NaN <=> 3.14，== 仍可用，但 < 会编译失败——因为 NaN < 3.14 在数学上无定义。

实际踩坑最多的地方，是与容器交互时的隐式期待冲突。std::set 要求严格弱序（strict weak ordering），而 <=> 默认生成的是强序（strong ordering）。两者不等价，但强序天然满足严格弱序要求，所以能用。但如果你手写 operator<=> 返回 partial_ordering，std::set<Task> 就会编译不过——因为 partial_ordering 不保证传递性，而 set 需要它。这时必须显式转成 strong_ordering：

auto operator<=>(const Task& other) const -> std::strong_ordering {
    // ... 同上逻辑，但声明返回 strong
}

最后提醒一个易忽略的实战细节：<=> 只对 const 成员函数生效。如果你的比较逻辑需要修改内部状态（比如缓存哈希值），它就不适用——这不是缺陷，而是信号：可变状态的比较，本身就违背了“比较应是纯函数”的直觉。此时该反思设计，而非强行绕过。

C++20 的 <=>，远不止是语法简化。它把散落的比较逻辑拧成一股绳，逼你直面类型的本质契约：我的对象，到底凭什么被说成“更大”或“相等”？写对一个 <=>，相当于给类型签了一份数学层面的承诺书——后续所有比较行为，都自动受其约束。这种约束感起初像枷锁，用熟了才懂：它省下的不是几行代码，而是深夜调试 map 插入失败时，那一声长叹。