Stream.min() 报 NullPointerException 是因比较器访问 null 字段所致，应使用 Comparator.nullsFirst()/nullsLast() 安全处理；空流返回 Optional，须用 orElse() 等方法避免 NoSuchElementException。
Stream.min() 报 NullPointerException 怎么办
直接对含 null 元素的集合调用 Stream.min()，只要比较器碰到 null 就会炸——哪怕只是 Comparator.comparing(obj -> obj.getValue()) 这种常见写法。根本原因不是 min() 本身拒绝空值，而是比较器在尝试调用 null.getValue() 时抛出异常。
解决思路不是绕开 min()，而是让比较器安全处理 null：
- 用
Comparator.nullsFirst()或Comparator.nullsLast()包装原始比较器，显式定义null的排序位置 - 避免在 lambda 中直接访问可能为
null的字段，改用方法引用或条件判断 - 如果业务逻辑明确不允许
null，应在流操作前用filter(Objects::nonNull)清洗
想取最小值但列表可能为空，怎么避免 NoSuchElementException
Stream.min() 返回的是 Optional<t></t>，不是直接返回对象。很多人忘了拆包就调用 .get()，一旦流为空立刻崩。这不是 bug，是设计使然。
正确姿势是始终通过 Optional 的 API 处理空情况：
- 用
.orElse(null)直接给默认值（注意：返回null可能把问题后移） - 用
.orElseGet(() -> new MyObj(...))延迟构造默认对象，避免无谓实例化 - 用
.ifPresent(min -> {...})仅在有结果时执行逻辑，不强制兜底 - 绝对不要无条件调用
.get()，除非你 100% 确保流非空且已校验过
按自定义字段比较时，Comparator.comparing() 和手动写比较器有啥区别
用 Comparator.comparing(Person::getAge) 看似简洁，但它底层会尝试对每个元素调用 getAge() —— 如果某个 Person 是 null，这里就挂了。而手动写的比较器可以控制空值逻辑：
Comparator<Person> cmp = (p1, p2) -> {
if (p1 == null && p2 == null) return 0;
if (p1 == null) return -1; // null 排最前
if (p2 == null) return 1;
return Integer.compare(p1.getAge(), p2.getAge());
};
更推荐组合式写法，清晰且复用性好：
-
Comparator.nullsFirst(Comparator.comparing(Person::getAge))→null排最前 -
Comparator.nullsLast(Comparator.comparing(Person::getName, String.CASE_INSENSITIVE_ORDER))→null排最后，字符串忽略大小写 - 注意：
Comparator.comparing()的第二个参数是值比较器（如String::compareTo），不是空值策略
性能和可读性之间怎么权衡：预过滤 vs 在比较器里处理 null
如果列表里 null 很少，用 filter(Objects::nonNull) 预清洗更直观，也避免比较器反复判空；但如果 null 出现频繁，且你本就要保留它们做排序（比如展示时把空项置顶），那必须在比较器里处理。
关键点在于语义是否匹配：
- “找最小有效对象” → 用
filter().min() - “按某字段排序，
null视为极小/极大值” → 用nullsFirst()/nullsLast() - 混合场景（例如：非空对象按字段比，
null对象按另一规则排）→ 手写比较器，别硬套工具方法
别为了省一行代码把空值逻辑塞进 lambda 主体，可读性和调试成本会陡增。比较器该独立就独立，哪怕只用一次。
