collections.sort排序对象列表必须提供comparator或元素实现comparable，否则编译报错；它就地修改原列表，不返回新列表，java 8+推荐用list.sort()替代。
用 Collections.sort 排序对象列表必须提供 Comparator
直接传入对象列表会编译报错：Collections.sort(list) 要求列表元素实现 Comparable；否则必须显式传 Comparator。这不是可选步骤，是强制类型检查。
- 常见错误现象：IDE 报红
The method sort(List<t>) in the type Collections is not applicable for the arguments (List<myobj>)</myobj></t> - 使用场景：比如按
User.age升序、按Product.name忽略大小写排序 - 推荐优先用 lambda，比匿名内部类简洁：
Collections.sort(users, (a, b) -> Integer.compare(a.getAge(), b.getAge())) - 注意 null 安全：lambda 里若字段可能为 null，别直接调
a.getName().compareTo(...)，先判空或用Comparator.nullsLast()
Comparator.comparing 是更安全、可读性更高的写法
相比手写 lambda，Comparator.comparing 自动处理取值逻辑和 null 情况，链式调用也直观。
- 参数差异：
comparing(User::getAge)返回升序比较器；加.reversed()变降序；comparing(User::getName, String.CASE_INSENSITIVE_ORDER)支持定制规则 - 性能影响：几乎无额外开销，底层仍是函数式接口调用，JVM 优化充分
- 容易踩的坑：方法引用不能带参数或副作用，
User::getAge必须是无参、非 void、非 static 的 getter - 示例：
Collections.sort(files, Comparator.comparing(File::lastModified).reversed())—— 按修改时间倒序
排序后原列表被就地修改，别误以为返回新列表
Collections.sort 是 in-place 操作，不返回新列表，也不创建副本。如果需要保留原始顺序，得提前 new ArrayList(original)。
- 常见错误现象：两次调用
sort发现第二次没效果，其实是第一次已把列表排好了 - 并发风险：若该列表正被其他线程遍历，排序期间可能抛
ConcurrentModificationException - 不可变集合陷阱：对
Arrays.asList()或Lists.newArrayList()结果调用sort没问题；但对Collection.unmodifiableList()调用会直接抛UnsupportedOperationException
Java 8+ 更推荐用 List.sort() 替代 Collections.sort()
两者行为完全一致，但 list.sort(comparator) 更符合面向对象直觉，且避免静态方法带来的“谁拥有这个操作”的困惑。
立即学习“Java免费学习笔记（深入）”；
- 兼容性：仅限 Java 8+；Java 7 及以下只能用
Collections.sort - 语法糖优势：可链式调用（虽然不常用），如
users.sort(comparing(User::getEmail)).forEach(...) - 容易忽略的点：如果
list是null，list.sort(...)会 NPE，而Collections.sort(null, ...)同样 NPE —— 别指望它帮你判空
