Stream.min() 返回 Optional 是因流可能为空，需用 orElse() 等安全取值；推荐 Comparator.comparing() 比较价格，注意 null 和 BigDecimal 处理；时间复杂度 O(n)，不等价于 sorted().findFirst()。
Stream.min() 返回 Optional 的原因
直接调用 Stream.min() 不会返回商品对象，而是返回 Optional<product></product>。这是因为它无法保证流非空——空流调用 min() 会返回 Optional.empty()，不抛异常，但如果你直接 .get() 就会炸出 NoSuchElementException。
常见错误现象：NullPointerException 或程序崩溃，往往是因为没检查 isPresent() 就强取值。
- 务必用
orElse(null)、orElseThrow()或ifPresent()处理空情况 - 如果业务上「必须有最便宜商品」，用
orElseThrow(() -> new IllegalStateException("商品列表为空")) - 如果允许无结果，别写
.get()，改用orElse(null)并后续判空
Comparator.comparing() 是最简写法
找最便宜商品，本质是按 price 升序取第一个。用 Comparator.comparing(Product::getPrice) 最直观，它自动处理 null 值（默认把 null 排在前面），但注意：如果 getPrice() 返回 Double 或 BigDecimal，且可能为 null，就得显式处理。
示例：
Product cheapest = products.stream()
.min(Comparator.comparing(Product::getPrice))
.orElse(null);
- 若
getPrice()返回int/double（基本类型），不会为null，放心用 - 若返回
Double，且某些商品价格为null，上面代码会让null被认为“最小”，导致结果错乱 - 此时应改用
Comparator.comparing(Product::getPrice, Comparator.nullsLast(Comparator.naturalOrder()))
避免用 Math.min() 或自定义 lambda 写 Comparator
有人写成 .min((a, b) -> Double.compare(a.getPrice(), b.getPrice()))，语法没错，但可读性差、易出错；更糟的是用 Math.min(a.getPrice(), b.getPrice()) 当比较器——这根本不是合法的 Comparator 实现，编译都过不去。
-
Math.min()返回数值，而Comparator的compare()必须返回负数/零/正数，语义不同 - lambda 中手写
Double.compare()比较冗余，不如用comparing()直接 - 如果价格字段是
BigDecimal，必须用compareTo()，不能用==或doubleValue()转换后比——精度丢失会导致排序错乱
性能与边界场景提醒
Stream.min() 是终端操作，会遍历全部元素一次，时间复杂度 O(n)，没有捷径。它不等价于先 sorted().findFirst()——后者会全排序（O(n log n)），明显更慢。
- 大数据量时，别误用
sorted(Comparator.comparing(...)).findFirst() - 如果集合已按价格索引（比如数据库查出来已排好序），就别走 Stream 流式找 min，直接取首元素更高效
- 多线程环境下，确保
Product类的getPrice()是线程安全的（比如字段是 final 或 volatile，或方法无副作用）
最便宜 ≠ 价格最低的那个对象引用，而是流中第一个满足最小值条件的元素——如果有多个同价商品，min() 返回的是它们中**在原始顺序里最先出现的那一个**，这点容易被忽略。
