reduce可在一次遍历中融合filter与map逻辑，通过在回调中判断条件并手动推入转换后的值；但存在逻辑耦合高、不可短路、可读性差等权衡。

reduce 可以在一次遍历中完成 map + filter 的组合逻辑，但不是简单“替代”，而是通过手动累积符合条件的转换结果，避免多次遍历数组。关键在于：在 reduce 的累加器中，只推入你想要的、已处理后的元素。

核心思路：用 reduce 模拟 filter + map 的融合逻辑

filter 负责“选”，map 负责“变”。reduce 本身不区分这两个动作，你需要在回调里自己判断是否保留、是否转换：

• 如果当前项不符合条件（如被 filter 排除），直接返回当前累加器（不添加）
• 如果符合条件，就对它做 map 的变换，再 push 到累加器中
• 初始累加器设为 []，最终得到的就是过滤后并转换过的新数组

一个典型例子：筛选偶数并平方

原写法（两次遍历）：

const nums = [1, 2, 3, 4, 5];
const result = nums.filter(x => x % 2 === 0).map(x => x * x); // [4, 16]

用 reduce 一次遍历实现：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

const result = nums.reduce((acc, x) => {
  if (x % 2 === 0) acc.push(x * x);
  return acc;
}, []); // [4, 16]

注意边界与可读性权衡

reduce 替代链式调用虽节省遍历次数，但也有代价：

• 逻辑耦合变高：过滤条件和映射逻辑写在一起，后期修改易出错
• 无法短路：filter + map 是惰性组合（ES2023 之前），而 reduce 总是遍历全部元素
• 可读性下降：尤其当转换逻辑复杂时，不如语义明确的 filter/map 直观
• 性能提升有限：除非数组极大或计算昂贵，否则 V8 等引擎优化下差异不明显

进阶：支持提前终止或更灵活累积

如果真需要“中断遍历”（比如找到第一个满足条件的转换值），reduce 不适合——应改用 find 或手写 for 循环。reduce 的设计本意是全量累积，强行 break 会破坏函数式习惯，且不可靠（return 不等于跳出）。真有这类需求，别硬套 reduce。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南