stream.reduce做复杂指标规约，关键在结果可复现、线程安全、逻辑可维护；须先验证指标的可结合性与中性初值，优先用三参数版本并配不可变累加器。
直接用 Stream.reduce 做复杂业务指标的增量规约，关键不在“能不能写出来”，而在于“结果是否可复现、线程是否安全、逻辑是否可维护”。多数踩坑源于误用双参数版、共享可变 identity 或忽略 combiner 的语义约束。
明确业务指标的数学结构
先判断指标是否满足「可结合性」和「中性初值」——这是 reduce 能成立的前提。例如：
- 总销售额：满足（
sum + sum = sum，identity = 0） - 平均客单价：不满足单值归约（需同时维护
sum和count，必须用三参数版或封装不可变容器） - 订单履约率 = 已履约订单数 / 总订单数：分子分母需同步累积，identity 应为
new long[]{0, 0}或自定义RatioAccumulator - 最近30天滚动活跃用户数（去重）：本质是集合合并，不能用 reduce，应改用
collect(Collectors.toSet())
优先选用三参数 reduce 版本
即使当前是串行流，也应默认使用三参数形式：stream.reduce(identity, accumulator, combiner)。它天然兼容并行，且逻辑边界清晰。
-
identity 必须是不可变对象（如
0L、BigDecimal.ZERO、ImmutableList.of()），禁止 new ArrayList() 或 new HashMap() -
accumulator 必须返回新对象，禁止修改入参（如
(acc, e) -> { acc.add(e); return acc; }是错的） -
combiner 必须与 accumulator 行为一致，且满足结合律：
combiner(a, combiner(b, c)) == combiner(combiner(a, b), c)
处理带状态的复合指标（如加权平均、分位数、滑动窗口统计）
这类指标无法靠单一数值承载中间状态，需设计轻量、不可变的累加器类：
- 定义
WeightedSumAccumulator：含sum: BigDecimal、weightSum: double字段，提供add(value, weight)和merge(other)方法，二者均返回新实例 - identity 设为
WeightedSumAccumulator.empty() - accumulator 写成
(acc, item) -> acc.add(item.getValue(), item.getWeight()) - combiner 写成
(a, b) -> a.merge(b) - 最终结果调用
finalAccumulator.getWeightedAverage()提取业务值
规避常见反模式
以下写法看似简洁，实则危险：
- 用
reduce(new HashMap(), (m, e) -> { m.put(e.key, e.val); return m; }, (a,b) -> { a.putAll(b); return a; })→ identity 可变，多线程污染 - 用
reduce(0, (s, e) -> s + computeBusinessLogic(e))→ 若computeBusinessLogic含缓存、日志、DB 查询等副作用，结果不可预测 - 用双参数版做平均值：
reduce(new double[]{0,0}, (a,e)->{a[0]+=e;a[1]++;return a;}, ...)→ 数组被复用，必出错 - 省略 combiner，却对 stream 调用
parallel()→ 运行时抛IllegalStateException或静默错误
真正稳健的做法：简单指标用内置收集器（Collectors.averagingDouble、Collectors.summarizingInt）；定制指标就老实用三参数 reduce + 不可变累加器。不复杂但容易忽略。
