前两天我在做一个很“真实”的需求：外卖平台要做日报，产品给我一串指标——今天订单总数、客单价、最长配送时长、是否存在“超时严重”的单子、以及“可能没数据时别炸”。

我第一反应是：写 for 循环，if 判断，临时变量堆一地。 然后第二反应是：这玩意儿用 Stream 的终止操作（reduction）+ Optional，一下就顺了。

一个真实痛点：统计写着写着就“炸了”

假设我们有一组外卖订单（简化成 Java record）：

import java.time.LocalDateTime;

public record Order(
        String id,
        String city,
int amountFen,          // 金额：分
int deliverMinutes,     // 配送时长：分钟
        LocalDateTime createdAt
){}

你要做这些事：

• 订单总数
• 最长配送时长（可能没有订单）
• 找到第一笔“严重超时”（比如 > 60 分钟）
• 判断是否存在“上海订单”
• 找到“金额最高”的订单（可能为空）

这类统计，本质上都是 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 的场景：

• 默认值很轻（比如 0、空字符串、空集合）
• 你不在乎默认值是怎么算出来的

如果默认值计算很重（比如要查配置/读文件/打 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();

适合：

• 只要命中就行，不在乎是谁
• 你准备上并行（parallelStream()）

我自己的经验：并行时别纠结顺序，顺序往往就是性能的敌人。（当然这话说得绝对了点，但大体如此）

三个“match”：判断类需求的最优解

比如产品问你：

• “今天是否存在上海订单？”
• “今天是不是所有订单都在 120 分钟内送达？”
• “今天有没有订单金额为 0（数据异常）？”

直接用：

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）一旦结果确定，就停止继续算。

• anyMatch：找到一个就停
• allMatch：发现一个不满足就停
• noneMatch：发现一个满足“禁止条件”就停

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、空、还是 异常？ 别让代码替你决定，让业务来决定。