Comparable负责类的自然排序，Comparator用于外部定义的多种排序；必须实现Comparable当类有唯一稳定大小关系；Comparator解决“一物多序”；二者不优先级，使用场景不同。
Comparable 和 Comparator 不是“配合使用”的关系，而是分工明确的两种排序策略：一个管类的自然顺序，一个管临时的、外部定义的顺序。混用时容易引发 ClassCastException 或排序失效，关键在“谁该实现哪个”。
什么时候必须实现 Comparable
当你的类有唯一、公认的大小关系（比如 Integer 小于大、String 字典序），且这个规则稳定不变，就该让类自己实现 Comparable。否则像 Collections.sort(list) 或 TreeSet 这类依赖自然顺序的 API 会直接抛 ClassCastException。
实操建议：
- 实现
compareTo(T o)时，返回负数/0/正数，不要写成return this.value - o.value（整数溢出风险） - 若字段为
null安全起见，用Objects.compare(a, b, Comparator.nullsFirst(Comparator.naturalOrder())) - 继承关系中，子类
compareTo必须兼容父类逻辑，否则TreeSet可能漏元素
Comparator 是解决“一物多序”的唯一途径
同一个类经常需要多种排序方式：按价格升序、按销量降序、按名称忽略大小写……这些都不能塞进 Comparable，否则违背单一职责，也破坏封装。此时必须用 Comparator 实例。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
常见写法：
- 匿名内部类（老项目还能见到）：
new Comparator<product>() { public int compare(Product a, Product b) { return Integer.compare(a.price, b.price); } }</product> - Lambda 更简洁：
(a, b) -> Integer.compare(a.price, b.price) - 静态方法引用：
Comparator.comparing(Product::getName).thenComparingInt(p -> p.stock)
注意：Comparator.nullsLast(Comparator.naturalOrder()) 比手写空值判断更安全、可读性更好。
Comparable 和 Comparator 同时存在时，谁优先
没有“优先级”。它们被用在完全不同的地方：
-
Arrays.sort(arr)或Collections.sort(list)默认调用元素的compareTo（即依赖Comparable） -
Arrays.sort(arr, comparator)或Collections.sort(list, comparator)显式传入Comparator，此时Comparable被完全忽略 -
TreeSet/TreeMap构造时没传Comparator，就强制要求元素实现Comparable；传了就只用那个Comparator
错误典型：把实现了 Comparable 的类放进 TreeSet，又额外传了一个逻辑冲突的 Comparator——结果不是报错，而是排序行为和你预期完全不一致，极难调试。
最容易被忽略的一点：泛型擦除会让 Comparable super T> 的签名变得微妙。如果写 class A implements Comparable<a></a>，但实际比较的是 B extends A 的实例，运行时可能因类型擦除导致 ClassCastException。稳妥做法是声明为 class A implements Comparable<object></object> 并在 compareTo 中做 instanceof 判断——虽然看起来怪，但在复杂继承场景下真有用。
