Collections.sort委托给List.sort是为了支持接口默认方法和行为定制化，使具体实现类可优化排序逻辑，提升扩展性与面向对象合理性。
Java 8 引入了 List.sort(Comparator) 方法，并将 Collections.sort 的实现改为直接调用它——这不是简单的代码搬运，而是 API 设计与底层机制协同演进的结果。
为什么 Collections.sort 要委托给 List.sort？
核心动因是支持 default 方法和接口行为定制化。Java 8 允许在接口中定义默认方法，List 接口借此获得了 sort 方法，使得具体实现类（如 ArrayList、LinkedList）可按需优化排序逻辑。而 Collections.sort 作为工具类静态方法，不再需要重复实现排序算法，只需转发请求即可。
-
Collections.sort(list, cmp)内部就是list.sort(cmp) - 对
ArrayList，sort会转为数组、调用Arrays.sort（Timsort） - 对
LinkedList，由于不支持随机访问，sort会先转成数组排序，再重建链表 - 自定义
List实现可重写sort，提供更优策略（比如基于索引缓存或特殊数据结构）
这种委托带来的实际影响
表面看只是调用链变短，但对开发者有几处关键变化：
- 空指针异常位置可能不同：以前
Collections.sort(null)抛出 NPE 在工具类里；现在委托后，NPE 实际由List.sort触发，堆栈更贴近实际对象 -
list.sort(null)和Collections.sort(list, null)行为一致，都要求元素自然有序（即实现Comparable），否则抛ClassCastException - 若使用不可变或只读
List（如List.of()），调用sort会直接抛UnsupportedOperationException，因为其sort默认实现就是抛异常
什么时候该用哪个？
语义上完全等价，选择取决于代码风格和上下文：
立即学习“Java免费学习笔记（深入）”；
- 面向对象风格优先：操作明确属于某个列表实例时，用
list.sort(comparator)更直观 - 函数式或工具类习惯：批量处理多个集合、或配合
Stream流式操作时，仍常用Collections.sort(list, cmp) - 注意兼容性：Java 7 及之前只能用
Collections.sort；Java 8+ 中二者可互换，但推荐优先使用list.sort，体现对接口契约的尊重
背后的设计逻辑：接口责任下沉
把排序逻辑从工具类“下放”到 List 接口，本质是让行为归属更合理——排序是列表自身的能力，不是外部工具强加的操作。这为后续扩展留出空间，例如：
- 未来某版本可为特定
List子类提供并行排序（如ParallelSortedList） - 响应式或惰性列表（如
StreamSupport.list()衍生类型）可实现延迟排序或部分排序 - 第三方集合库（如 Eclipse Collections、Guava）也能通过实现
List.sort提供专属优化
不复杂但容易忽略：这个看似微小的委托改动，其实是 Java 面向接口编程和默认方法能力落地的一个典型缩影。
