Collections.sort() 报错因元素未实现 Comparable 接口；解决方法是让类实现 Comparable 并正确重写 compareTo()，或使用 Comparator 处理多规则排序。
为什么直接调用 Collections.sort() 会报错
因为 Collections.sort() 要求元素类型实现 Comparable 接口，否则抛出 ClassCastException 或提示 “cannot be cast to java.lang.Comparable”。你写了个 User 类，没声明它“能比大小”，Java 就真不会比。
常见错误现象：Exception in thread "main" java.lang.ClassCastException: User cannot be cast to java.lang.Comparable
- 只重写了
toString()或equals()，没动Comparable - 实现了
Comparable，但泛型写错，比如写成implements Comparable<String> - 类是
final的，但接口方法没正确覆盖（少见，但编译会报错）
怎么让自定义类支持自然排序：实现 Comparable 接口
核心就两步：声明实现接口 + 重写 compareTo() 方法。返回负数表示“当前对象小”，0 表示相等，正数表示“当前对象大”。
使用场景：你想让这个类默认按某个字段（比如 id 或 name）升序排，且整个项目里多数排序都基于这个逻辑。
立即学习“Java免费学习笔记（深入）”；
参数差异注意：compareTo() 参数类型必须和泛型一致，比如 class User implements Comparable<User>，那方法签名必须是 public int compareTo(User other)，不能是 Object。
public class User implements Comparable<User> {
private int id;
private String name;
public User(int id, String name) {
this.id = id;
this.name = name;
}
@Override
public int compareTo(User other) {
return Integer.compare(this.id, other.id); // 按 id 升序
}
}
性能影响：无额外开销，compareTo() 是实例方法，内联友好；兼容性也很好，JDK 1.2 就支持，所有集合工具类都认。
多个排序规则怎么办：别硬改 compareTo()，用 Comparator
一旦你发现“有时按 id，有时按 name，还有时要倒序”，就别再往 compareTo() 里塞 if-else —— 那违背了“自然顺序”的本意，也容易引发维护混乱。
更合理的方式是保留 Comparable 做最常用、最稳定的排序（比如主键），其余逻辑全交给 Comparator：
Collections.sort(list, Comparator.comparing(User::getName))list.sort(Comparator.comparing(User::getId).reversed())- 字段为 null？加
Comparator.nullsLast()避免NullPointerException
这样既不污染领域模型，又灵活。而且 Comparator 可以复用、组合、测试，Comparable 不行。
容易被忽略的细节：null 值、浮点数、字符串比较
compareTo() 方法里自己处理 null，Comparable 合约明确要求不能返回 null，也不能抛出 NullPointerException（除非你文档写明“不允许 null 字段”）。
- 字段可能为 null？用
Objects.compare(a, b, Comparator.nullsFirst(String::compareTo)) - 用
double字段排序？别用>或==，用Double.compare(a, b)—— 浮点误差会导致排序错乱 - 字符串忽略大小写？别写
a.toLowerCase().compareTo(b.toLowerCase())，用String.CASE_INSENSITIVE_ORDER.compare(a, b)
这些不是“高级技巧”，是上线后真实踩过的坑：null 导致服务崩溃，浮点字段排序颠倒，中文排序乱序……写 compareTo() 时，得当它是生产级代码来审。
