Collectors.reducing有三种核心用法：1.无初始值版返回Optional<T>；2.带初始值版返回确定类型T，需单位元；3.带映射版支持“先转换再归约”，适用于对象属性聚合、字符串拼接及自定义对象合并，使用时须确保操作符满足结合律且初始值为单位元。
理解 reducing 的三种核心用法
Collectors.reducing 不是万能求和工具，而是归约逻辑的通用表达载体。它提供三个重载版本，对应不同抽象层级的需求：
-
无初始值版：`reducing(BinaryOperator
)` → 返回 Optional<T>，流为空时为 empty，适合必须校验结果存在的场景 -
带初始值版：`reducing(T identity, BinaryOperator
)` → 返回确定类型 T，identity 是单位元（如求和用 0、乘积用 1），确保空流不抛异常 - 带映射版：`reducing(U identity, Function<T,U>, BinaryOperator<U>)` → 支持“先转换、再归约”，是处理对象字段、类型跃迁最常用的形式
对对象属性做安全聚合（推荐模式）
实际业务中，多数规约不是针对原始数值，而是从对象中提取字段后计算。这时第三种形式最自然且不易出错。
例如统计订单总金额：
List<Order> orders = List.of(
new Order("A", 99.9),
new Order("B", 150.0),
new Order("C", 0.0)
);
double total = orders.stream()
.collect(Collectors.reducing(0.0, Order::getAmount, Double::sum));
// 结果：249.9，即使 orders 为空也返回 0.0
关键点：
- 初始值 0.0 类型需与映射后类型一致（
Function<Order,Double>） -
Double::sum满足结合律，支持并行流；若自定义 lambda，务必保证满足结合律 - 避免写成
reducing(0, o -> (int)o.getAmount(), Integer::sum)—— 类型截断风险高
实现非数值类规约：字符串拼接与自定义对象合并
reducing 不限于数字运算。只要二元操作符满足结合律和单位元语义，就能扩展使用。
比如将用户名按逗号连接，并加前缀：
List<User> users = List.of(new User("Alice"), new User("Bob"), new User("Charlie"));
String joined = users.stream()
.collect(Collectors.reducing(
"Users:",
u -> u.getName(),
(a, b) -> a.isEmpty() ? b : a + ", " + b
));
// 输出："Users: Alice, Bob, Charlie"
再比如合并多个配置对象（假设 Config 支持 merge 方法）：
Config defaultConf = new Config();
Config merged = configs.stream()
.collect(Collectors.reducing(
defaultConf,
Function.identity(),
Config::merge // 要求 merge 是结合律且 defaultConf 为单位元
));
注意：此时必须确保 defaultConf.merge(x).equals(x) 成立，否则单位元失效，空流或单元素流行为异常。
规避常见陷阱
用好 reducing 的关键是守住两个底层契约：
- 结合律必须成立：`(a op b) op c == a op (b op c)`。例如 `String::concat` 满足，但 `"x".concat(a).concat(b)` 和 `a.concat("x").concat(b)` 行为不同，就不安全
- 初始值要是单位元：`identity op x == x op identity == x`。求最大值不能用 0 作 identity（负数会出错），应改用 `reducing(BinaryOperator.maxBy(Comparator.naturalOrder()))` 或配合 `Optional.orElseThrow()`
- 并行流下，各分段归约结果需能再次用同一 op 合并 —— 这正是要求结合律的根本原因
