前两天我在做一个很“真实”的需求：外卖平台要做日报，产品给我一串指标——今天订单总数、客单价、最长配送时长、是否存在“超时严重”的单子、以及“可能没数据时别炸”。
我第一反应是：写 for 循环，if 判断，临时变量堆一地。 然后第二反应是：这玩意儿用 Stream 的终止操作（reduction）+ Optional，一下就顺了。
一个真实痛点：统计写着写着就“炸了”
假设我们有一组外卖订单（简化成 Java record）：
import java.time.LocalDateTime;
public record Order(
String id,
String city,
int amountFen, // 金额：分
int deliverMinutes, // 配送时长：分钟
LocalDateTime createdAt
){}
你要做这些事：
这类统计，本质上都是 reduction：把一堆数据压成一个结果。 Stream 里对应的就是各种终止操作：count / max / min / findFirst / findAny / anyMatch / allMatch / noneMatch。
Reduction 的本质：把“多”变成“一”
1）count()：最常用，但别小看
long total = orders.stream().count();
为什么好用？因为它表达的是“我要数量”，而不是“我要怎么循环累加”。 （而且写 for 循环时很容易把筛选条件写散，后来自己都读不懂。）
最大/最小：max() / min() 为什么要返回 Optional？
你以为最大值一定存在？其实不是
比如今天某个城市没有订单：
var maxDeliver = orders.stream()
.map(Order::deliverMinutes)
.max(Integer::compareTo); // 返回 Optional<Integer>
关键点：max/min 的返回值是 Optional<T>，不是 T。
因为 stream 可能为空，最大值“根本不存在”。 老写法通常会返回 null，然后你就会遇到经典 NPE —— 线上还不一定好复现。
Optional：不是“更麻烦”，而是“更明确”
我对 Optional 的理解一直很朴素：
Optional 就是在告诉你：这里可能没有值，你必须面对这个事实。
1）拿值：orElse / orElseGet / orElseThrow
假设我们要最大配送时长，没数据就显示 0：
int maxMinutes = orders.stream()
.map(Order::deliverMinutes)
.max(Integer::compareTo)
.orElse(0); // 没数据就用 0
这里我个人习惯用 orElse 的场景：
如果默认值计算很重（比如要查配置/读文件/打 RPC），用 orElseGet：
int maxMinutes = orders.stream()
.map(Order::deliverMinutes)
.max(Integer::compareTo)
.orElseGet(() -> loadDefaultMaxMinutesFromConfig());
小技巧：orElseGet 是“懒执行”，只有 Optional 为空才会调用。很多人写 orElse(load...)，结果每次都执行 load（哪怕 Optional 有值），性能坑就这么来的。
如果“没有值就是异常”，用 orElseThrow：
int maxMinutes = orders.stream()
.map(Order::deliverMinutes)
.max(Integer::compareTo)
.orElseThrow(() -> new IllegalStateException("今天居然一单都没有？"));
2）消费值：ifPresent / ifPresentOrElse
有时候你不需要“拿出来”，只需要“有就做点事”：
orders.stream()
.filter(o -> o.deliverMinutes() > 60)
.findFirst()
.ifPresent(o -> System.out.println("严重超时订单：" + o.id()));
更完整一点：有值打印，没有值也打印：
orders.stream()
.filter(o -> o.deliverMinutes() > 60)
.findFirst()
.ifPresentOrElse(
o -> System.out.println("严重超时订单：" + o.id()),
() -> System.out.println("今天没有严重超时，客服可以喘口气")
);
findFirst 和 findAny：别只看名字
1）findFirst()：强调“顺序”
var firstBad = orders.stream()
.filter(o -> o.deliverMinutes() > 60)
.findFirst();
适合：
2）findAny()：强调“随便来一个”，并行更爽
var anyBad = orders.parallelStream()
.filter(o -> o.deliverMinutes() > 60)
.findAny();
适合：
我自己的经验：并行时别纠结顺序，顺序往往就是性能的敌人。（当然这话说得绝对了点，但大体如此）
三个“match”：判断类需求的最优解
比如产品问你：
直接用：
boolean hasShanghai = orders.stream().anyMatch(o -> "上海".equals(o.city()));
boolean allUnder120 = orders.stream().allMatch(o -> o.deliverMinutes() <= 120);
boolean noneZeroAmount = orders.stream().noneMatch(o -> o.amountFen() == 0);
这三个方法有个共同优点：短路（short-circuit）一旦结果确定，就停止继续算。
Optional 的“正确姿势”：别再 get() 了
我见过不少代码这样写：
var max = orders.stream().map(Order::deliverMinutes).max(Integer::compareTo);
int v = max.get(); // ⚠️
这等于在说： “我知道它一定有值，但我不想证明，我赌。”
这不是 Optional 的正确用法。get() 为空时会直接抛 NoSuchElementException，比 NPE 更隐蔽（因为你以为 Optional 已经“安全”了）。
同理，下面这种也不香：
if (max.isPresent()) {
int v = max.get();
}
写着写着又回到了“手动判空”。
更推荐你用前面讲的三类方式：
- 需要一个值：
orElse / orElseGet / orElseThrow - 需要做点事：
ifPresent / ifPresentOrElse - 需要继续变换：
map / filter / flatMap / or
Optional 也能“流水线”：map + filter + or
比如我想拿“金额最高订单”的 ID，但只接受金额 > 30 元（3000 分），否则当作没有：
String bestOrderId = orders.stream()
.max((a, b) -> Integer.compare(a.amountFen(), b.amountFen()))
.filter(o -> o.amountFen() > 3000)
.map(Order::id)
.orElse("今天没有超过30元的单子");
这段代码我很喜欢，原因是：每一步都在表达业务，而不是在表达控制流。
Optional 的组合：flatMap 的用武之地
这个场景很常见： A 方法返回 Optional，B 方法也返回 Optional，你想连起来。
比如：订单可能有优惠券，优惠券可能还要再算折扣，任何一步都可能没有：
import java.util.Optional;
record Coupon(String code, double discountRate){} // 0.9 表示9折
Optional<Coupon> findCoupon(Order o){ /* ... */return Optional.empty(); }
Optional<Double> finalPayYuan(Order o){
// 订单金额（元）
double raw = o.amountFen() / 100.0;
return findCoupon(o)
.map(c -> raw * c.discountRate()); // 有券就打折
}
如果你的 map 返回的本身就是 Optional，就用 flatMap 把 Optional“压平”：
Optional<Double> safeDiscountRate(Coupon c){ /* ... */return Optional.of(c.discountRate()); }
Optional<Double> finalPayYuan2(Order o){
double raw = o.amountFen() / 100.0;
return findCoupon(o)
.flatMap(this::safeDiscountRate) // Optional<Optional<Double>> -> Optional<Double>
.map(rate -> raw * rate);
}
一句话记忆：flatMap = map + flatten。（当然，这里还有另一种写法，我们后面再聊，比如把 Optional 转成 Stream 再 flatMap。）
更进一步：把 Optional 变成 Stream，优雅过滤“无效结果”
假设你有一堆用户 ID，要查用户对象，但查询可能失败：
record User(String id, String name){}
Optional<User> lookup(String id){ /* ... */return Optional.empty(); }
很多人会这样写：
var users = ids.stream()
.map(this::lookup)
.filter(Optional::isPresent)
.map(Optional::get)
.toList();
能跑，但有点“回到过去”。
更优雅的是：
var users = ids.stream()
.map(this::lookup)
.flatMap(Optional::stream) // Optional -> 0/1 个元素的 Stream
.toList();
不存在的用户会自然“消失”，留下来的都是有效 User。
常见坑总结：Optional 不是“处处都要用”
我自己的规则（也踩过坑）：
- 返回值：适合用 Optional 表达“可能没有”
- 参数：一般不建议用 Optional 当参数（调用方会很别扭）
- 字段：不建议把 Optional 当成员变量（额外对象开销、序列化也麻烦）
- 集合里塞 Optional：尽量别这么干（要的是值，不是盒子）
结尾：我学到的“更像工程”的一件事
Stream 的 reductions（count/max/find/match）解决的是：把“数据流”变成“答案”。
Optional 解决的是：把“可能没有”这件事，从隐藏的 NPE，变成你必须写下来的业务选择。
当你把这两套组合起来，代码就会从“能跑”变成“好读、好改、好兜底”。
最后留一个我经常问自己的问题，给你也当个思考题：
你这个统计结果，如果没有数据，到底应该是 0、空、还是 异常？ 别让代码替你决定，让业务来决定。
10个月宝宝每天需要喝多少奶粉？
