comparable是类内置的自然排序接口，需类内部实现且仅支持一种顺序；comparator是外部可插拔策略，支持多规则、免改源码、可处理null。
Comparable 是类的“内置排序身份证”
一个类实现了 Comparable 接口，就等于向整个 JVM 宣告：“我有公认的自然顺序”。比如 Integer 比大小、String 按字典序排——这些都不用额外说明，集合（如 TreeSet）、工具方法（如 Collections.sort()）会自动调用它的 compareTo() 方法。
关键点：
- 必须在类内部实现，改排序逻辑就得改源码，耦合高
- 只能有一种自然顺序（比如
Person只能固定按age升序，不能同时支持按姓名或降序） - 若用于
TreeMap的 key 或TreeSet元素，且没实现Comparable，运行时直接抛ClassCastException -
compareTo()的参数类型和当前类一致（T o），是“自己比别人”
Comparator 是随时可插拔的“外部排序策略”
Comparator 不属于类本身，而是独立存在的比较规则。你可以为同一个类写多个 Comparator：按年龄升序、按姓名长度倒排、甚至按拼音首字母——全都不用碰原类代码。
典型使用场景：
立即学习“Java免费学习笔记（深入）”；
- 类源码不可修改（第三方库对象、JDK 类未实现
Comparable的情况） - 需要临时切换排序逻辑，比如分页查询时前端传参决定按
createTime还是score排 - Java 8+ 中大量用 Lambda 简写：
(a, b) -> a.getName().compareTo(b.getName()) -
compare()接收两个同类型参数（T o1, T o2），是“拿两个别人比”
null 处理差异：一个踩坑高频点
Comparable 的 compareTo() 方法里如果传入 null，绝大多数实现（包括 JDK 自带的）会直接抛 NullPointerException；而 Comparator 明确允许处理 null——你可以自己定义 null 排最前、最后，或直接报错。
常见错误现象：
- 对含
null的List<person></person>调用Collections.sort()报空指针 → 原因：Person 实现了Comparable，但compareTo()没判空 - 想让
null排末尾，却写了Comparator.nullsLast(Comparator.naturalOrder())→ 注意：这仅对实现了Comparable的类型有效；自定义类得用Comparator.comparing(..., Comparator.nullsLast(...))
什么时候该选哪个？看三件事
不用背理论，动手前问自己：
- 这个排序规则是否“天经地义”？比如
Money类按金额排序、OrderId按字符串字典序——适合Comparable - 是否要支持多种排序？比如后台管理页要按状态、创建时间、更新人三列分别点击排序 → 必须用
Comparator - 能不能改那个类？不能改（比如
java.time.LocalDateTime）→ 只能用Comparator
实际项目里，90% 的实体类建议只实现 Comparable 定义主键/业务主序（如 ID 或 code），其余维度全部交给 Comparator 动态构造——既清晰，又避免未来加字段时反复改 compareTo()。
