Collections.min()仅在给定集合中找最小元素，不支持先筛选后取最优；需用Stream.filter()先过滤特定业务属性（如状态为PAID），再用min()配合reversed()取最优（如金额最高）。
Collections.min() 本身不支持“按业务属性筛选后再取最优”，它只负责在给定集合中找“最小元素”——前提是集合元素可比较（实现 Comparable）或提供外部比较器（Comparator）。所谓“快速筛选出具有特定业务属性的最优变量”，实际需要两步：先过滤（filter），再比较（min）。Java 8+ 推荐用 Stream API 组合完成，而非直接依赖 Collections.min()。
明确业务场景：什么是“特定业务属性”？
比如有一个订单列表 List<order></order>，你想找出“状态为已支付（PAID）且金额最高的订单”。这里：
- “特定业务属性” = 状态为
PAID（过滤条件） - “最优变量” = 金额最高（即按
amount降序取第一个，等价于取max；若坚持用min，可对金额取负值或改用Comparator.reverseOrder()）
推荐做法：用 Stream.filter() + Stream.min()（带 Comparator）
这是最清晰、安全、符合语义的方式：
Optional<Order> bestPaidOrder = orders.stream()
.filter(order -> OrderStatus.PAID.equals(order.getStatus()))
.min(Comparator.comparing(Order::getAmount).reversed()); // 金额最高 → 反向比较
说明：
-
filter()先筛出符合条件的对象，避免无效比较 -
min(Comparator)在剩余元素中找“最小值”，但通过reversed()实现“最大值”逻辑 - Optional，天然处理空集合或无匹配项的情况，比
Collections.min()抛NoElementException更健壮
不推荐强行用 Collections.min() 的情况
有人试图先用 stream().filter().collect(Collectors.toList()) 转成新列表，再传给 Collections.min(list, comparator)。这可行但冗余：
- 多一次中间 List 创建，增加内存开销
- 未利用 Stream 的短路特性（如配合
findFirst()可提前终止） - 异常处理更麻烦：需手动判空，否则运行时抛异常
如果必须用 Collections.min()（如维护老代码）
确保两点：
- 过滤后列表非空：
if (filtered.isEmpty()) throw new IllegalArgumentException("No qualified item"); - 提供明确的
Comparator，不要依赖对象自带compareTo()（除非该逻辑恰好匹配你的业务“最优”定义）
示例：
List<Order> paidOrders = orders.stream()
.filter(o -> PAID.equals(o.getStatus()))
.collect(Collectors.toList());
if (paidOrders.isEmpty()) {
throw new IllegalStateException("No paid order found");
}
Order topOrder = Collections.min(paidOrders, Comparator.comparing(Order::getAmount).reversed());
核心就一点：**“筛选”和“比较”是两个正交操作，Stream 天然支持链式组合；Collections.min 是纯归约工具，不负责过滤。用对工具，逻辑才简洁可靠。**
