C++20 的 defaulted spaceship operator：少写代码，多点确定性

刚升级到 C++20 项目，翻旧类时发现同事在 operator<=> 后面加了个 = default;，还顺手删了所有 ==, !=, <, >, <=, >=——你心里是不是也咯噔一下？这真能行？编译器真懂你想比什么？别急，这不是魔法，是 C++20 给我们的一次“信任交付”：只要你的类型语义清晰、成员可比较，defaulted <=> 就能自动生成一套逻辑一致、无歧义的全部比较操作符。

但关键来了：它不是“自动补全”，而是“语义推导”。很多人误以为 = default; 是偷懒捷径，结果一跑测试就发现 std::sort 崩了，或者 std::map 插入顺序诡异。问题往往不出在语法，而出在你没意识到编译器正按字节序逐个比成员，而你的业务逻辑根本不是字典序。

举个实在的例子。假设你有个 Person 类：

struct Person {
    std::string name;
    int age;
    bool is_active;
};

写 auto operator<=>(const Person&) const = default; 后，比较逻辑是：先比 name（字典序），相等再比 age（数值大小），再比 is_active（false < true）。这看起来合理？对通讯录排序可能没问题；但如果你的业务里，“活跃用户优先”是硬规则，那 is_active 就该排第一位——而 defaulted <=> 不会猜你的心思，它只忠实地按声明顺序展开。

所以，defaulted <=> 的前提不是“成员多”，而是“成员顺序即比较优先级”。一旦声明顺序和业务语义错位，生成的比较行为就会悄悄偏离预期。这不是 bug，是契约：你提供结构，它兑现逻辑；你给错结构，它就给你错逻辑。

另一个常被忽略的细节：defaulted <=> 对 union、含 volatile 成员、或有不可比较子对象的类型直接报错——不是静默降级，而是硬性拒绝。这其实是保护机制：它不假装能比，而是逼你直面设计矛盾。比如你加了个 std::mutex 成员（显然不可比较），编译失败反而是好消息：提醒你这个类本就不该进容器或参与排序。

更实用的一招：用 = default; 配合 [[nodiscard]] 和 const 限定，把比较意图显式钉死。像这样：

auto operator<=>(const Person& other) const noexcept = default;

noexcept 不是装饰——它让 std::vector<Person> 在扩容时敢于移动而非复制（因为移动构造/赋值若 noexcept，容器才敢优化）；const 则明确告诉调用者：“我不会改你任何状态”；而 [[nodiscard]] 虽不能加在 operator<=> 上（标准不允许），但你可以把它加在封装比较逻辑的辅助函数里，避免 if (a <=> b) 写成 if (a <=> b == 0) 这种易错模式。

还有人担心性能：逐个成员比会不会慢？实测中，现代编译器对 defaulted <=> 生成的代码优化极好——常内联、常向量化、甚至合并相邻整型比较。真正拖慢的从来不是 defaulted 本身，而是你把 std::string 或 std::vector 放在比较链前端，又没预分配好内存。优化方向不在运算符，而在数据布局：把高频比较字段（如 ID、状态码）往前放，把大对象往后挪，效果远超手写一堆 if-else。

最后说个反直觉但高频的坑：defaulted <=> 默认生成的是 strong_ordering，但如果你的类型存在“等价但不相等”的场景（比如浮点数 NaN），就必须手动返回 partial_ordering 并处理 std::isnan。C++ 不替你做这种语义抉择——它只保证：你选 strong，它就严格遵循全序三定律（自反、反对称、传递）；你选 partial，它就允许 a <=> a == std::partial_ordering::unordered。

写到这儿，你应该能感觉到：defaulted spaceship operator 不是语法糖，而是一面镜子——照出你对类型语义的理解深度。它省掉的是样板代码，但要求你更早、更清醒地定义“什么才算两个对象相等”、“谁该排在谁前面”。当你开始为每个新类型思考成员顺序、noexcept 性质、以及 ordering 类型时，代码的健壮性已经悄然提升了一截。

下一次，当你想敲 = default; 之前，不妨停半秒：这个顺序，真是我想要的比较逻辑吗？