Java Collectors.teeing 如何合并两条统计结果：中间集合、空输入与结果对象

订单列表页同时要显示“订单总额”和“已支付笔数”时，最容易写出两次遍历：先 summingInt，再 filter 计数。Collectors.teeing 可以把同一条 Stream 分给两个下游 Collector，最后用一个合并函数组装成结果对象；本例运行后得到 Summary[totalAmount=2840, paidCount=2]，空列表也会稳定返回 Summary[totalAmount=0, paidCount=0]。

先把调用方真正需要的两个字段说清楚

后台订单概览通常只需要两个数字：全部订单金额，以及其中 paid=true 的订单数。返回一个命名结果对象比返回 Map 或 Object[] 更稳，调用方不必记字符串键和数组下标。

record Order(String id, int amount, boolean paid) {}
record Summary(int totalAmount, long paidCount) {}

static Summary summarize(List orders) {
    return orders.stream().collect(Collectors.teeing(
        Collectors.summingInt(Order::amount),
        Collectors.filtering(Order::paid, Collectors.counting()),
        Summary::new
    ));
}

这里的两个下游结果类型不同：第一个是 Integer 语义上的金额总和，第二个是 Long 语义上的计数，Summary::new 只负责把它们接到一起。它没有重新遍历订单，也没有暴露 Collector 的内部状态。

teeing 的数据路径：一条输入流，两个独立下游

运行 repro/OrderTeeingDemo.java 后，三笔订单的金额是 1200、980、660，已支付订单是 A17 和 C21。输出中的 orders=3、Summary[totalAmount=2840, paidCount=2] 和 paidIds=[A17, C21] 正好对应输入数据，说明合并函数拿到的是两个完整的最终统计结果。

这个边界很重要：teeing 的合并函数不会看到每一笔 Order，只会看到两个下游的最终值。如果合并阶段还需要订单明细，就应让下游 Collector 产生包含明细的对象，或者显式保留中间集合，别指望从 Summary::new 里“回头取数据”。

参数设计：把过滤放在计数 Collector 的里面

“已支付数量”有两种写法。可以先 filter(Order::paid) 再 count()，也可以像示例一样把条件放进 Collectors.filtering。作为 teeing 的第二个下游，后者把“计数口径”封装在 Collector 参数里，读代码时更容易和第一个金额下游对齐。

如果金额可能超过 int，应把金额字段和 Collector 换成 long，再使用 summingLong。不要为了让示例通过而忽略这个边界，订单统计的类型选择本身就是接口契约的一部分。

空输入不是异常，先验收默认结果

同一个示例还运行了 summarize(List.of())。测试报告里的 empty=Summary[totalAmount=0, paidCount=0] 说明两个下游都提供了自然的零值，合并函数仍然可以构造结果对象。这个结果适合订单列表为空但页面仍要渲染统计卡片的场景。

但“空输入返回零”不等于“所有业务都应该返回零”。例如没有订单时页面要显示“暂无数据”，可以把 Summary 外面再包一层状态，或在进入 Stream 前做业务判断。teeing 只负责 Collector 组合，不替调用方决定展示语义。

什么时候保留中间集合更合适

一次消费是 teeing 的直接收益，但不是唯一目标。若后续既要计算统计数字，又要按支付状态展示订单 ID，当前例子已经额外用 partitioningBy 做了分组。生产代码里如果这种明细被多个模块重复使用，先建一个经过校验的中间模型往往更清楚；如果只是同一接口返回两个聚合数，teeing 会更紧凑。

• 只返回少量聚合值：优先考虑 teeing，用 record 固定字段语义。
• 需要多次遍历或返回明细：保留中间集合，避免重复查询或重复消费不可复用的数据源。
• 下游逻辑带副作用：先拆开写成命名方法，别把网络调用、写库动作塞进合并函数。

相关问题

Collectors.teeing 会让 Stream 自动并行吗？

不会。它只是组合两个下游 Collector，是否并行仍由 Stream 的顺序和 Collector 的特性决定；本例使用普通顺序流。

两个下游 Collector 能返回不同类型吗？

可以。合并函数接收两个结果，本例正是把金额数值和支付数量组装成 Summary。

为什么不用两次 stream() 调用？

当数据已经在内存集合中时，两次遍历未必有问题；teeing 更适合希望一次消费、且两个统计口径天然属于同一个结果对象的场景。

把结果对象当成接口边界

Collectors.teeing 最值得保留的不是一行代码，而是清晰的结果协议：第一个下游负责总额，第二个下游负责支付数量，合并函数负责构造 Summary。先用真实输入和空列表验收，再决定是否需要中间集合或更宽的业务状态，代码会比“先收集一堆对象、最后再猜字段含义”更容易维护。