先记住这个答案
reduce 从较小索引向较大索引处理，reduceRight 方向相反，但二者回调参数仍是累加器在前、当前值在后。显式初始值决定第一步的累加器；没有初始值时，会从对应方向找到第一个存在的元素作为起点。对于理想的可交换累加，方向可能不影响结果；字符串拼接、减法、函数组合或带副作用的处理则可能不同。选择时应写出两三步展开式，确认要的是左折叠还是右向扫描，不要把 reduceRight 理解成对最终结果 reverse。
- 方向改变而回调参数顺序不变
- 初始值决定折叠的起点与结果类型
- 带副作用和顺序敏感运算需要逐步展开
用可见括号保留每一步执行痕迹
数字相加很容易掩盖方向差异，下面使用字符串构造括号，把当前累加结果和新输入都保留下来。这样无需依赖调试器，就能直接看出 A、B、C 分别在哪一步参与。
两个调用使用相同回调和相同初始值，唯一变化是方法方向。若同时改回调参数或初始值，就难以判断差异究竟来自遍历顺序还是运算定义，面试推导也容易混乱。
const items = ['A', 'B', 'C'];
const combine = (acc, item) => '(' + acc + '+' + item + ')';
console.log(items.reduce(combine, 'S'));
console.log(items.reduceRight(combine, 'S'));
console.log(JSON.stringify(items));查看输出与解释
(((S+A)+B)+C)
(((S+C)+B)+A)
["A","B","C"]reduceRight 从 C 开始传入回调，累加器仍放在第一个参数。原数组顺序保持不变，这与先对共享数组执行会修改它的 reverse 不是同一操作。
函数组合需要结合回调写法判断
若希望依次执行解析、转换、格式化，可以用左折叠表示数据流；若希望把一组函数包装成由右侧函数先作用于输入的组合，则右向折叠可能更直观。关键是回调如何把函数和已有结果组合。
不要只因为方法名带 Right 就声称最终函数一定按某种业务顺序执行。组合阶段和调用阶段可能是两个时刻，应使用带记录的纯测试函数确认实际调用顺序，再决定公开 API 的表达方式。
边界输入会改变回调调用次数
没有提供初始值且只有一个存在元素时，该元素直接成为结果，回调不会执行；空数组或全为空位且无可用初值时会抛错。提供初始值能让空输入拥有明确结果，但初值必须符合运算语义。
两种方法通常跳过不存在的索引，回调内部若修改未访问位置又会影响之后读取。业务聚合最好避免边遍历边改源数据，并保证每一步返回下一轮所需的累加器，防止意外传入 undefined。
容易答错的地方
- 以为 reduceRight 会交换回调两个参数
- 方法只改变访问方向，累加器与当前值的参数位置保持一致。若误写回调顺序，减法、拼接或嵌套结构都会得到另一套运算，应先展开小输入验证而不是凭名字判断。
- 用 reverse 后 reduce 替换时忽略原数组
- 普通 reverse 会修改调用数组，可能影响其他共享它的代码。即便最终折叠值相似，也不代表副作用等价；需要保留原数组时使用不修改的方案，并检查稀疏结构与读取时机。
面试官还会怎么问？
求和时方向完全无关吗？
对理想数学整数加法常可忽略方向，但 JavaScript Number 存在浮点舍入，大数与小数混合可能出现次序差异。若业务要求精确计算，应选择合适表示并明确数值误差要求。
右折叠能直接得到反向数组吗？
可以通过回调构造，但这只是某一种回调定义，并不是 reduceRight 固有的返回类型。返回什么由初始累加器和每步返回值决定，单纯反向复制应优先考虑表达意图更直接的方法。
异步回调可以直接放进去吗？
async 回调返回 Promise，下一轮可能收到 Promise 作为累加器而非最终值。若确实用折叠构造异步链，需要显式等待前一步；普通顺序任务通常用清楚的循环更容易处理错误与退出。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。