Java中实现Comparable接口必须重写compareTo()方法，返回负数、0或正数表示小于、等于、大于，需遵守自反性、对称性、传递性契约，仅依赖不可变字段，泛型参数必须为当前类类型。
Comparable 接口必须实现 compareTo() 方法
Java 中，让一个类具备“自然排序”能力，核心就是实现 Comparable 接口，并重写 compareTo()。这个方法返回负数、0 或正数，分别表示“小于”“等于”“大于”当前对象。它不是用来打印或调试的，而是被 Collections.sort()、TreeSet、Arrays.sort() 等内部调用的。
常见错误是只比较一个字段（比如只比 id），但实际业务中往往需要多级排序（如先按状态，再按创建时间）。这时不能简单 return 两个字段相减——整数溢出或浮点精度问题会导致结果错乱。
- 用
Integer.compare(a, b)替代a - b - 字符串用
name1.compareTo(name2)，别用==或.equals()判定大小 - 对可能为
null的字段，提前判空并约定 null 排在前面还是后面（例如Objects.compare(name1, name2, Comparator.nullsLast(String::compareTo))是 Java 9+ 的写法，但Comparable里得手动处理）
实体类实现 Comparable 时要保持自反性、对称性、传递性
这是 compareTo() 的契约，违反会导致 TreeSet 插入失败、Collections.sort() 抛 IllegalArgumentException: Comparison method violates its general contract!。最典型的破约场景是：在比较逻辑中混入了可变字段（比如某个字段后期被修改），或者用了随机值、系统时间等不稳定因子。
- 只依赖不可变字段（
final字段最佳）或逻辑上稳定的计算结果 - 避免在
compareTo()中调用可能抛异常的方法（如远程调用、IO） - 如果实体有继承关系，子类重写
compareTo()时，必须先调用super.compareTo()再追加自己的字段比较，否则父类字段差异会被忽略
和 Comparator 比较器的关系不是替代，而是分工明确
Comparable 定义的是“这个类默认怎么排”，而 Comparator 是“现在临时想换个方式排”。比如 User 类实现了按 id 自然排序，但某次查询需要按注册时间倒序，就该传入 Comparator.comparing(User::getRegisterTime).reversed()，而不是改写 compareTo()。
容易踩的坑是：有人为了“灵活”把 compareTo() 写成根据某个静态变量切换排序逻辑，这会让类的行为变得不可预测，也破坏了序列化/反序列化一致性。
-
Comparable是类的固有属性，应稳定、无副作用 - 多个排序需求，优先用
Comparator，而非污染compareTo() - 若真需要运行时决定自然顺序（极少见），应通过组合不同
Comparable实现类来达成，而不是在方法体内 if-else
泛型参数必须是当前类本身
声明必须是 class User implements Comparable<User>，不能写成 Comparable<Object> 或 Comparable<Person>（即使 User 继承 Person）。JVM 在运行时会检查类型擦除后的实际参数，不匹配会导致编译失败或 ClassCastException。
另一个细节：泛型参数不能是通配符（如 Comparable<?>），也不能是父类类型（如 Comparable<Serializable>），否则集合工具类无法安全调用 compareTo()。
- IDE 通常能自动补全正确泛型，但手写或重构时容易写错
- 如果类是泛型类（如
Box<T>），那么Comparable<Box<T>>才合法，不能省略T - 使用 Lombok 的
@Data时，默认不生成compareTo()；要用@EqualsAndHashCode+ 手动实现，或用@Data配合@EqualsAndHashCode(callSuper = false)并确保字段可比
真正难的不是写几行 compareTo()，而是判断哪些字段该参与自然排序、它们的优先级是否随业务演进仍合理，以及当团队多人维护时能否一眼看出排序逻辑是否被无意破坏。自然排序一旦上线，就很可能被下游序列化、缓存、日志等环节隐式依赖，改起来成本远高于新增一个 Comparator。
