Scala中reduceLeft与reduceRight的累加器参数位置是否存在差异？

这一参数顺序差异是Scala标准库的刻意设计，核心目的是让算子书写逻辑和方法的默认结合顺序完全对齐，降低理解成本。

对于任意列表List(a, b, c, d)，两个reduce方法的运算展开规则如下：

• reduceLeft(op) 等价于 (((a op b) op c) op d)：每次运算的左操作数是之前所有元素的累加结果，右操作数是下一个待处理的当前元素。因此算子参数顺序设计为(累加器, 当前元素)，和左右操作数的位置完全对应，写算子时不需要额外调整参数顺序，比如reduceLeft(_ + _)就直接等价于从左到右依次累加，语义完全一致。
• reduceRight(op) 等价于 a op (b op (c op d))：每次运算的右操作数是后面所有元素的累加结果，左操作数是当前待处理的元素。因此算子参数顺序设计为(当前元素, 累加器)，同样和左右操作数的位置对应，reduceRight(_ + _)就直接等价于从右到左依次累加，语义直观。

以测试代码为例，测试用列表为List(5,4,3,2,1)，reduceRight传入的算子为curr - acc，按展开规则实际运算逻辑为：
5 - (4 - (3 - (2 - 1)))
计算过程和输出日志完全匹配：2-1=1 → 3-1=2 →4-2=2 →5-2=3，最终得到结果3。

如果强行把两个方法的参数顺序做成一致，反而会导致开发者写算子时需要手动反转参数，违背直觉。另外测试代码中reduceLeft的参数命名是反向的，reduceLeft的第一个参数才是累加器，第二个是当前元素，调整命名为(acc, curr)后逻辑会更清晰。

内容的提问来源于stack exchange，提问作者Shivam Sahil