不一定。Java对象排序仅在使用Collections.sort()或Arrays.sort()且不传Comparator，或放入TreeSet/TreeMap时才需实现Comparable；否则可用Comparator，尤其适合临时、多维或第三方类排序。
Java对象排序必须实现Comparable接口吗？
不一定。只有用Collections.sort()或Arrays.sort()对对象数组/列表原地排序，且不传Comparator时，才强制要求类实现Comparable。否则会抛ClassCastException：「java.lang.ClassCastException: xxx cannot be cast to java.lang.Comparable」。
常见踩坑场景：把自定义对象直接塞进TreeSet或作为TreeMap的key，没实现Comparable又没传Comparator，运行时报错而非编译报错。
- 想复用排序逻辑（比如多个地方按同一规则排），优先实现
Comparable，定义自然顺序 - 临时性、多维度、或仅某处需不同排序逻辑，直接传
Comparator更轻量 - 若类已发布且无法修改源码（如第三方库对象），只能靠
Comparator
compareTo()方法里怎么写才不出错？
核心是遵守「自反性、对称性、传递性、一致性」——但实操中，90%的问题出在空值处理和基本类型比较上。
比如字段是Integer age，直接写o1.age - o2.age会NPE；写o1.age.compareTo(o2.age)又可能因o1.age == null崩掉。
立即学习“Java免费学习笔记（深入）”；
- 永远先判空：
Objects.compare(a, b, Comparator.nullsLast(Integer::compareTo))比手写if安全 - 避免用减法算差值（如
a - b）比较整数：溢出时结果翻转，Integer.MAX_VALUE - (-1)会变负数 - 字符串比较别用
==或String.compareTo()忽略大小写需求时，用String.CASE_INSENSITIVE_ORDER.compare(a, b) - 多个字段排序，用「链式比较」：先比
name，相等再比age，推荐Comparator.comparing(User::getName).thenComparing(User::getAge)
用list.sort()还是Collections.sort()？
两者行为一致，都原地排序，但list.sort()是List接口默认方法，从Java 8起支持；Collections.sort()是工具类静态方法，兼容老版本。
区别在于调用主体和泛型推断：前者更直观（users.sort(comparator)），后者需显式传入List参数（Collections.sort(users, comparator)）。性能无差异。
- 如果
list是ArrayList或LinkedList，两者底层都走Timsort，稳定且高效 -
list是不可变集合（如Arrays.asList()返回的）也能用，但排序后若原底层数组被外部修改，行为未定义 - 别对
null元素调用sort()——除非Comparator明确处理了null，否则抛NullPointerException
为什么按日期排序总乱序？
因为Date、LocalDateTime这些类本身实现了Comparable，但容易误用「时间戳数值」或「字符串格式化后比较」。
典型错误：new SimpleDateFormat("yyyy-MM-dd").format(date1).compareTo(...)——格式化后字符串比的是字典序，不是时间先后；或者用date1.getTime() - date2.getTime()有溢出风险。
- 直接用对象自带
compareTo()：date1.compareTo(date2)或time1.isBefore(time2) - 若需忽略时分秒，先截断：
localDateTime.truncatedTo(ChronoUnit.DAYS)再比 - 数据库查出的
java.sql.Timestamp可直接和LocalDateTime混用？不行！必须显式转换，否则compareTo()可能返回0但实际不等
排序逻辑真正难的不是写法，而是想清楚「相等对象是否必须保持原有相对位置」——stable sort（稳定排序）在Java里默认满足，但一旦自己手写交换逻辑或混用不同排序API，这点就容易丢。
