Collections.sort() 默认按自然顺序排序，要求元素实现Comparable接口；报错常见原因包括元素未实现Comparable、含null值或泛型类型不匹配；对ArrayList和LinkedList行为一致但LinkedList性能更差。
Collections.sort() 默认就是按自然顺序排序，前提是 List 里的元素实现了 Comparable 接口（比如 String、Integer、Long 等）。直接调用即可，不用额外传比较器。
为什么调用 Collections.sort(list) 有时会报错？
最常见的错误是：List 中的元素类型没有实现 Comparable，比如自定义类没重写 compareTo()，或混入了 null 值。
-
ClassCastException：例如List<object></object>里塞了String和Integer，它们没有共同的自然序规则 -
NullPointerException：当 list 包含null，且该类型自然排序不支持 null（如String的compareTo()遇到 null 就崩） - 编译不通过：泛型擦除后类型不匹配，比如声明为
List<Object>却想靠自然序排——JVM 不知道该用哪个compareTo
Collections.sort() 对 ArrayList 和 LinkedList 行为一样吗？
行为一致，但底层策略不同：它内部会把 LinkedList 先转成数组再排序，最后回写。所以对 LinkedList 调用 Collections.sort() 实际做了两次遍历 + 一次数组拷贝，性能比 ArrayList 差。
- 小数据量（
- 大数据量下，如果原始结构是
LinkedList且频繁排序，建议先转成ArrayList再排：new ArrayList<>(list) - 排序后若需保持链表特性（如频繁中间插入），排序完再转回
LinkedList没意义——排序本身已破坏链表的“链式优势”
自然顺序和字典序、数值序是一回事吗？
不是。自然顺序由元素自身的 compareTo() 定义，而这个定义可能和直觉不符：
-
String是按 Unicode 码点逐字符比较（即字典序），"10""2" 成立（因为'1''2'） -
Integer是按数值大小，10 > 2，没问题 - 自定义类如
User若只按name字段实现compareTo，那age或id完全不影响自然序 - 注意：
BigDecimal的自然序是数值序；但new BigDecimal("1.0")和new BigDecimal("1.00")在自然序下不相等（compareTo()返回非零）
真正容易被忽略的是：自然顺序依赖于运行时实际对象类型，而不是变量声明类型。比如 List<Object> list = new ArrayList<>(); list.add(5); list.add("hello"); —— 这种混合类型列表根本不能安全调用 Collections.sort()，编译能过，运行必炸。
