三路比较运算符<=>可自动生成全部六个比较运算符，避免手动实现导致的语义不一致、维护困难等问题，但需注意浮点数、指针等特殊类型限制及operator==必须单独定义。
它能用一个 operator 替代全部六个比较运算符（==、!=、<、<=、>、>=），让编译器自动生成其余逻辑，大幅减少手写错误和维护成本。
为什么手动实现6个比较运算符容易出错
嵌入式场景中常见结构体如 SensorReading，成员一变就得同步改6处；更隐蔽的问题是语义不一致——比如 operator< 比较时用了字典序，而 operator== 忘了比某个字段，结果 a == b 为 false，但 a < b 和 a > b 全为 false，违反全序假设。排序算法（如 std::sort）依赖这种一致性，一旦打破就会出现未定义行为。
无序列表形式的典型坑点：
-
operator!=直接写成!(*this == other)看似省事，但若operator==后续被优化成 memcmp，而operator!=没同步改，就可能因 padding 字节不同导致误判 -
operator<=写成*this < other || *this == other，在调试模式下多一次函数调用，影响实时性关键路径 - 成员顺序调整后，
operator<的 if-else 链没重排，导致比较逻辑与字段声明顺序脱节
auto operator<=>(const T&) const = default 能做什么
只要所有成员类型都支持 （如 int、std::string、其他已定义该运算符的类），编译器就按声明顺序逐个比较，遇到第一个不等的成员就返回结果，跳过后续字段。这和手写字典序逻辑完全一致，且零维护成本。
立即学习“C++免费学习笔记（深入）”；
但要注意：
- 不能用于含
float或double成员的类——因为浮点数比较需std::partial_ordering，而= default推导出的是std::strong_ordering，编译失败 - 如果类里有指针或自定义句柄（如
FILE*），默认生成会直接比较地址值，通常不是你想要的语义 - 嵌入式资源受限时，
= default可能比手写精简版多一次成员访问（比如先取x再取y），但差异极小，优先保正确性
手动实现 operator<=> 时怎么选返回类型
返回类型不是随便写的：std::strong_ordering 表示“相等即完全可互换”，适用于传感器 ID、时间戳这类整型字段；std::weak_ordering 适合忽略大小写的字符串比较；std::partial_ordering 是浮点数唯一合法选择——否则 NaN 1.0 会返回 std::strong_ordering::greater 这种误导结果。
常见误用：
- 对含
float value的结构体强行返回std::strong_ordering，导致NaN参与比较时行为未定义 - 在嵌入式固件版本号比较中（如
"v2.1.0-rc"），用std::strong_ordering但没处理后缀逻辑，结果"v2.1.0-rc" "v2.1.0"返回equal，实际应为less - 返回类型写成
auto而不显式指定，某些老编译器（GCC 10.2 之前）会推导失败
operator== 必须单独定义吗
必须。C++20 明确规定：即使写了 operator，operator== 也不会被自动生成。原因很实际——字符串比较时，== 可先比长度再比内容，比三路比较快得多；传感器数据若含 padding，== 用 memcmp 可能误判，但手写能跳过 padding 字节。
所以标准做法是：
- 用
= default生成operator，再额外加一行bool operator==(const T&) const = default; - 如果需要定制（比如忽略某些字段），就手写
operator==，但operator仍可保留= default或手动实现 - 别写
bool operator==(const T&) const { return *this other == 0; }——这会强制走三路逻辑，浪费一次完整比较
最常被忽略的一点：三路比较不是银弹。它解决的是“写全6个运算符”的工程问题，但不改变比较本身的语义复杂度。比如版本号解析、带单位的物理量比较、或加密哈希值的恒定时间比较，仍得自己写逻辑—— 只是帮你把这一个逻辑复用到所有比较场景里。
