Stream.reduce()连乘正确写法是用reduce(1, (a,b)->a*b)，空流返回1；常见错误包括：用0作identity、忽略并行流需提供combiner、误用n为列表而非范围、不处理int溢出。
Stream.reduce() 连乘的正确写法和常见错误
直接用 Stream.reduce() 做连乘，最常踩的坑是传入空流时返回 Optional.empty() 或抛 NoSuchElementException。Java 的 reduce(identity, accumulator) 重载能规避这个问题，但 identity 必须是“单位元”——对乘法来说就是 1，不是 0（否则整个结果恒为 0）。
示例：对 List<integer> nums = Arrays.asList(2, 3, 4);</integer> 连乘：
int product = nums.stream()
.reduce(1, (a, b) -> a * b); // ✅ 返回 24注意点：
- 若列表为空，
reduce(1, ...)仍返回1，符合数学直觉 - 用
Integer::sum类比，乘法对应的是Integer::multiply，但该方法 Java 8 没提供，需手写 lambda 或方法引用(a, b) -> a * b - 整数溢出不会报错，结果静默翻转——如
IntStream.rangeClosed(1, 20).reduce(1, (a,b)->a*b)得到负数，此时应换用BigInteger
用 reduce 实现阶乘：输入必须是单个正整数，不是列表
阶乘本质是 1 × 2 × 3 × ... × n，它操作的是一个范围，不是已有列表。误把 n 当作列表传给 stream().reduce() 会导致编译失败或逻辑错乱。
正确做法是先生成 1..n 的流，再连乘：
int n = 5;
int factorial = IntStream.rangeClosed(1, n)
.reduce(1, (a, b) -> a * b); // ✅ 返回 120关键区别：
-
IntStream.rangeClosed(1, n)生成的是原始int流，避免装箱开销；用Stream.iterate()或Arrays.asList()构造列表再流式处理是低效且易错的 - 若
n = 0或n = 1，rangeClosed(1, 0)返回空流，reduce(1, ...)自然返回1，无需额外判断 - 超过
13!就会溢出int，生产环境建议用BigInteger版本：
BigInteger factorial = IntStream.rangeClosed(1, n)
.mapToObj(BigInteger::valueOf)
.reduce(BigInteger.ONE, BigInteger::multiply);为什么不用 collect(Collectors.reducing())？
有人试图用 collect(Collectors.reducing(...)) 替代 reduce()，但这是过度设计。两者的语义和性能并无优势：
-
reducing(identity, mapper, combiner)多一层函数映射，对纯数值连乘无必要 -
collect()是为并发流或复杂容器设计的，单线程顺序流用reduce()更直接、更易读 - 当需要同时做 map 和 reduce（比如先取绝对值再连乘），才考虑
collect(reducing(...))，否则纯属绕路
容易被忽略的类型安全问题
reduce() 的三个参数版本（identity, accumulator, combiner）在并行流中必须提供 combiner，否则结果不可靠。但多数人只测试了顺序流，上线后开启并行才发现连乘结果偶尔错误。
例如：
// ❌ 错误：并行流下缺少 combiner，结果未定义 nums.parallelStream().reduce(1, (a,b)->a*b);
正确写法：
// ✅ 并行安全：combiner 必须与 accumulator 一致（乘法满足结合律） nums.parallelStream().reduce(1, (a,b)->a*b, (a,b)->a*b);
更稳妥的做法是：除非明确需要并行，否则别用 parallelStream()；若必须并行，确保 accumulator 和 combiner 完全相同，且操作满足结合律——加法、乘法、最大值/最小值可以，字符串拼接（非交换律）或自定义对象合并则需格外小心。
