Collections.min()需元素实现Comparable或传Comparator，空集合抛NoSuchElementException，不支持null，性能优于Stream.min()但无Optional防护。
直接用 Collections.min() 找自然顺序最小值
只要集合元素实现了 Comparable 接口（比如 String、Integer、LocalDateTime），Collections.min() 就能直接返回自然顺序下最小的元素。它内部调用的是元素自身的 compareTo() 方法。
常见错误：传入空集合会抛出 NoSuchElementException，不是 NullPointerException —— 这点容易误判异常类型。
- 确保集合非空，或提前用
collection.isEmpty()检查 - 不支持
null元素：哪怕只有一个null，也会在比较时触发NullPointerException - 对
TreeSet或已排序列表反复调用min()不如直接取首元素高效（但语义不同：前者是通用接口，后者依赖结构）
List<integer> nums = Arrays.asList(5, 2, 8, 1); Integer min = Collections.min(nums); // 返回 1</integer>
用 Comparator 参数实现自定义最小值逻辑
第二个重载方法 Collections.min(Collection 允许你完全控制“最小”的定义。它不关心元素是否可比较，只按你给的 compare() 规则执行一次遍历。
典型场景：找最长字符串、按某个字段排序的对象中字段值最小的那个、忽略大小写的字符串比较。
- 避免在
Comparator中抛异常（比如空指针未处理），否则min()会中断并抛出该异常 - 推荐用
Comparator.comparing()链式写法，比匿名类更安全简洁 - 若比较逻辑涉及耗时操作（如 IO、正则匹配），别在
compare()里做——它会被多次调用
List<string> words = Arrays.asList("apple", "banana", "cherry");
String shortest = Collections.min(words, Comparator.comparing(String::length)); // "apple"</string>
和 Stream.min() 的关键区别在哪
Collections.min() 是传统集合工具方法，单次遍历、无中间流对象、不支持并行；Stream.min() 返回 Optional，天然规避空集合异常，但有装箱开销和额外对象创建。
性能上，小集合几乎无差别；大集合且需链式操作时，Stream 更灵活；纯找最小值且确定非空，Collections.min() 更轻量。
-
Collections.min()要求集合本身支持迭代，不能用于无限流或某些特殊集合（如 Guava 的ImmutableSortedSet的子集视图可能不支持） -
Stream.min()可以接filter()、map()等前处理，Collections.min()必须传处理后的集合 - 两者都要求
Comparator是无状态的；有状态的比较器会导致结果不可预测
容易被忽略的边界情况
很多人只测了正常数据，上线后遇到奇怪的 ClassCastException 或空指针才排查——问题往往出在泛型擦除和运行时类型不一致上。
- 传入原始类型集合（如
ArrayList而非ArrayList）时，编译器无法检查Comparator类型，运行时报ClassCastException - 使用 lambda 写
Comparator时，若参数类型没显式声明（如(a, b) -> ...），IDE 可能推断错，导致编译失败或逻辑错误 -
Collections.min()不保证稳定性：多个相等最小值时，返回任意一个（不一定是第一个），别依赖顺序
真正麻烦的不是语法，而是当集合来自外部输入、含混合类型或部分 null 时，min() 的行为会立刻暴露设计盲区。
