Java Stream.reduce有三种重载：1.无初始值型返回Optional，要求流非空；2.有初始值型以identity为起点并满足恒等律；3.并行型含accumulator与combiner，支持分段计算合并。
Stream的reduce操作本质是“折叠”——把一串元素按规则一步步合并成一个结果。它不是简单循环，而是函数式归约，核心在于累加逻辑可拆分、可组合，尤其在并行场景下才真正体现价值。
三种重载形式怎么选？
关键看是否需要初始值、是否涉及类型转换、是否走并行流：
- 流非空且不关心空集合 → 用
Optional<T> reduce(BinaryOperator<T>)，比如找最大值：stream.reduce(Integer::max) - 需默认结果（如空列表返回0或""）→ 用
T reduce(T identity, BinaryOperator<T>)，注意identity必须满足恒等律：对任意t，acc.apply(identity, t) == t；求和用0、拼接用""、乘积用1 - 并行处理 + 类型转换（如List<String>→Integer长度总和）→ 用三参数版：
U reduce(U identity, BiFunction<U, ? super T, U>, BinaryOperator<U>)，其中combiner只在并行时生效，且必须与accumulator兼容（通常与accumulator相同，如Integer::sum）
为什么并行reduce容易出错？
并行流会把数据分片，每片独立调用accumulator生成中间结果，最后用combiner合并。这要求两个数学前提：
-
结合律成立：
acc(acc(a,b),c) == acc(a,acc(b,c))，否则分片顺序不同结果就不同。加法、最大值满足；字符串拼接a+b满足，但b+a不满足（顺序敏感） -
identity对combiner也中性：即
combiner.apply(identity, u) == u。若用""为初始值、String::concat为combiner，完全合规；但若误用(a,b)->b+a作combiner，就破坏了中性
违反任一条件，结果不可预测——这不是bug，是设计使然。
常见应用场景与写法要点
reduce不是万能聚合工具，它适合“无状态、纯函数、可交换”的场景。典型用法：
-
数值聚合：求和、乘积、极值。极值推荐用
max()/min()（语义清晰），但自定义比较器时reduce更灵活，如按字符串长度找最长：stream.reduce("", (a,b)->a.length()>=b.length()?a:b, (x,y)->x.length()>=y.length()?x:y) -
字符串拼接：避免用
+在循环中拼接（产生大量临时对象），改用Collectors.joining()更高效；若坚持reduce，初始值用""，累加器用(s, t) -> s.isEmpty() ? t : s + " " + t，再trim - 构建不可变对象：如把Map.Entry流聚合成新Map，但要注意线程安全——reduce返回新Map，天然无竞争，比collect用ConcurrentHashMap更简洁
reduce vs collect：什么时候该换？
reduce专注“单值产出”，collect专注“容器构建”。当目标是List、Set、Map、分组、分区时，collect更合适，因为：
- collect内置并发支持（如
Collectors.toConcurrentMap()） - collect的supplier+accumulator+combiner三元组与reduce结构一致，但封装了容器创建逻辑，避免手动new ArrayList等
- reduce拼接字符串易产生O(n²)复杂度（字符串不可变），而
Collectors.joining()底层用StringBuilder，是O(n)
简单说：要一个数、一个字符串、一个自定义对象 → reduce；要一个集合、一个统计报表、一个分组结构 → collect。
