提起数组的reduce方法大多数前端开发者的状态是面试前背过“累加器”“归并”这些概念真到项目里却很少主动用。我观察过不少团队的代码评审reduce常常被两派人争论一派觉得它晦涩难懂看到就想改成for循环另一派把它当成万能工具什么逻辑都往里塞。我站后者但中间踩过不少坑也慢慢摸出了它的使用边界。这篇文章不打算重复 MDN 上的语法说明而是想分享我在实际项目里用reduce的真实场景包括几个高频业务写法、几个让我半夜排查 bug 的边界情况以及什么时候应该果断放弃它。想真正掌握reduce光背 API 是不够的得把它的求值规则、返回值机制、以及和你手写循环之间的等价关系都理清楚才能在业务里用得顺手。1. 先别急着记 API把 reduce 的求值规则刻进脑子1.1 回调的四个参数真正要紧的是前两个reduce的签名大家都见过arr.reduce(callback, initialValue)。回调里有四个参数分别是累加器accumulator、当前值currentValue、当前索引index、原数组array但日常 95% 的场景只需要前两个。index偶尔会用到比如想在遍历中记录位置至于array我几乎没在业务代码里用过。理解reduce的关键不在参数名而在“每一次回调的返回值会变成下一次回调的第一个参数”这个闭环。换句话说reduce是在用一个函数把数组里的值和状态不断折叠fold成一个结果。初次上手时你只需要时刻问自己一个问题这一轮处理完我要给下一轮留下什么东西1.2 初始值的有无直接决定遍历从哪里开始这是很多人忽略的规则。当你不传第二个参数initialValue时reduce会把数组的第一个元素当作初始累加值然后从第二个元素开始遍历。传了initialValue遍历则从第 0 项开始。别小看这个差异它会影响回调被调用的次数还会在空数组场景下直接抛错。// 不传初始值回调执行 3 次 [1, 2, 3, 4].reduce((acc, cur) acc cur); // 这次遍历从索引 1 开始acc 初始为 1 // 步骤123, 336, 6410 // 传初始值回调执行 4 次 [1, 2, 3, 4].reduce((acc, cur) acc cur, 0); // 步骤011, 123, 336, 6410我建议在业务代码里始终显式传入初始值。不只是为了语义清晰更是为了规避空数组抛TypeError的雷。1.3 用一个展开表格理解归并过程假设我们要计算[2, 3, 4]的累积差值初始值传10轮次上一轮返回的 acc当前值 cur返回结果1102828353541最终结果是1。这个表格看起来简单但它揭示了一个本质reduce的回调像一条流水线前一个工位处理完的半成品会直接送到下一个工位。这个思维方式比记住任何 API 细节都有用。2. 业务代码里真正高频的六个归并场景2.1 数据汇总求和、平均、极值一个回调全搞定最常见的自然是求和。写forEach累加的人很多但reduce在表达“把一组数字折叠成一个总和”这个语义时更直接const orders [ { amount: 99, status: paid }, { amount: 199, status: unpaid }, { amount: 299, status: paid } ]; const totalPaid orders.reduce((sum, order) { return order.status paid ? sum order.amount : sum; }, 0);注意这里顺带实现了“一边过滤一边求和”不需要先filter再reduce。如果数据量只有几十条性能差异可以忽略但代码确实少了一次数组遍历。放在真实业务里这就意味着一个从接口返回的订单列表你可以用一次归并算出已支付总额、未支付总额、均价和最大单笔金额而不用生成多个中间数组。2.2 数组转映射表把列表变成字典这个场景我几乎每周都会遇到后端返回一个用户列表而前面的业务逻辑需要频繁按 ID 查找用户。先用reduce构建映射表再按 ID 取值比每次find遍历整个数组要高效得多代码也更清晰const users [ { id: 1, name: 张三 }, { id: 2, name: 李四 }, { id: 3, name: 王五 } ]; const userMap users.reduce((acc, user) { acc[user.id] user; return acc; }, {});也有人用Object.fromEntries(users.map(u [u.id, u]))两种写法等价但我个人偏好reduce因为当你想在转表的同时做点额外处理时比如过滤无效用户、给每个元素加一个额外字段reduce不需要改造成两段逻辑。不过要注意上面的写法如果直接写acc[user.id] user而不return acc第一次回调返回的是赋值表达式的值也就是user对象第二轮acc就变成这个用户对象了再给acc[user.id]赋值就会出错。2.3 多维数组扁平化递归与一次归并的结合处理嵌套数组也是高频需求。直接用flat(Infinity)当然省事但有些场景需要你在扁平化过程中同时做转换或者你对浏览器环境的兼容性有要求。reduce的递归写法是个很好的兜底方案const nested [1, [2, [3, 4]], 5]; function flatDeep(arr) { return arr.reduce((acc, val) { return acc.concat(Array.isArray(val) ? flatDeep(val) : val); }, []); } flatDeep(nested); // [1, 2, 3, 4, 5]这里的核心思路是遇到数组元素就递归调用flatDeep遇到普通值就直接concat进结果。concat返回新数组因此每次返回的都是一个干净的数组不会污染上一次的引用。2.4 去重并统计次数维护一个计数 Map数组去重用Set大家都懂但“去重并统计每个元素出现次数”的场景reduce几乎是最顺手的工具。比如统计一份日志里各个错误类型出现的次数const errors [timeout, network, timeout, auth, network, timeout]; const countMap errors.reduce((acc, error) { acc[error] (acc[error] || 0) 1; return acc; }, {}); // 结果{ timeout: 3, network: 2, auth: 1 }如果希望保持插入顺序可以用Mapconst countMap errors.reduce((acc, error) { acc.set(error, (acc.get(error) || 0) 1); return acc; }, new Map());这个模式在数据报表、埋点统计里很常见。值得注意的是acc在整个归并过程中始终是同一个对象引用这也是reduce的一个隐藏特性如果你返回的是同一个对象的引用那状态是共享的。用好了很高效用不好则会遇到后面提到的“浅拷贝污染”问题。2.5 按字段分组比手写 groupBy 更灵活业务里把订单按状态分组、把商品按分类分组需求差不多就是“给我一个对象key 是分组字段value 是数组”。reduce实现起来非常固定const orders [ { id: 1, category: food, amount: 30 }, { id: 2, category: drink, amount: 15 }, { id: 3, category: food, amount: 45 } ]; const grouped orders.reduce((acc, order) { (acc[order.category] acc[order.category] || []).push(order); return acc; }, {}); // 结果 // { // food: [{ id: 1, amount: 30 }, { id: 3, amount: 45 }], // drink: [{ id: 2, amount: 15 }] // }有些新环境已经支持Object.groupBy但不想引入 polyfill 的老项目里reduce这段代码就是最稳定的分组方案。你还可以在分组的同时做汇总比如按分类聚合总金额const categoryTotal orders.reduce((acc, order) { acc[order.category] (acc[order.category] || 0) order.amount; return acc; }, {});2.6 连续片段收集识别数组中的“上升趋势”这是我遇到过一个比较有意思的场景。拿到一份股票或指标数据需要把连续上涨的区间找出来。reduce在处理“依赖前一个元素的状态”时有天然优势因为acc可以携带上下文const prices [100, 102, 105, 104, 103, 107, 110]; const risingSegments prices.reduce((acc, price, index) { if (index 0) return acc; if (price prices[index - 1]) { // 当前比前一个高说明处于上涨段 if (!acc.current) { acc.current [prices[index - 1]]; acc.segments.push(acc.current); } acc.current.push(price); } else { // 上涨中断 acc.current null; } return acc; }, { segments: [], current: null });虽然这个例子稍微复杂一点但它展示了reduce的另一面它不只是用来做数学累加还可以做带状态的扫描。把acc当成一个“携带上下文的游标”很多本来需要for循环加外部变量的逻辑都可以塞进reduce逻辑更聚合副作用更少。3. 进阶玩法用 reduce 搭函数组合与异步流水线3.1 用 reduce 实现 pipe把嵌套调用变成平铺管道函数式编程里有个经典操作叫pipe把多个函数从左到右组合起来上一个函数的输出直接变成下一个函数的输入。手写嵌套是fn3(fn2(fn1(x)))这种从里往外读的反人类结构用reduce则可以变成const pipe (...fns) (input) fns.reduce((acc, fn) fn(acc), input); const add (n) n 10; const multiply (n) n * 2; const subtract (n) n - 5; const calc pipe(add, multiply, subtract); calc(3); // (3 10) * 2 - 5 21这个实现的内部逻辑很纯粹input先作为acc第一个函数执行后返回结果再把它当成第二个函数的参数一路传下去。pipe在复杂数据处理、中间件逻辑、配置处理中都很实用而且比一层层嵌套调用容易 debug因为你可以随时在中间tap一个函数打印当前值。如果你想让函数从右往左组合可以用reduceRight效果等价于手写的compose。这里要注意方向性reduce是左折叠reduceRight是右折叠结果是不同的。3.2 用 reduce 把 Promise 串起来异步队列的标准写法前端经常遇到“多个请求必须按顺序执行前一个完成后再发下一个”的需求比如逐个上传文件、依次拉取分页接口。这个场景最常见的实现是for...of加await但如果你手头已经是一个任务数组用reduce可以写得更紧凑const tasks [ () saveFile(a.txt), () saveFile(b.txt), () saveFile(c.txt) ]; tasks.reduce((promiseChain, task) { return promiseChain.then(() task()); }, Promise.resolve()).then(() { console.log(所有任务已完成); });关键在于初始值是Promise.resolve()然后每一步都返回一个新的 Promise。注意回调里task()只会在前一个 Promise resolve 之后才被调用这就是串行的核心。要是改写成Promise.all三个任务就是并发执行的虽然代码更简单但语义完全不同。提示想在串行中传参怎么办promiseChain.then((data) task(data))即可。每个task的返回值会作为下一个 then 的入参继续传递配合reduce的折叠特性可以构建一个“带状态流转”的异步管道。3.3 reduce 作为状态机的底层机制当你在reduce回调里使用外部变量时实际上是在“作弊”。真正纯粹的reduce应该完全通过acc传递状态。但在工程里我们并不追求绝对纯函数。我发现把reduce理解成“有限状态机”会很有帮助acc就是状态每次回调根据当前值和当前状态计算下一个状态。const events [login, pageview, click, logout, login]; const sessionLog events.reduce((acc, event) { if (event login) { acc.push({ type: event, sessionId: acc.length }); } else if (event logout) { acc.push({ type: event, sessionId: acc.length - 1 }); } else { acc.push({ type: event, sessionId: acc.length }); } return acc; }, []);这个例子说明了为什么有些问题用reduce天然比map合适map要求每个元素独立映射而reduce允许后面的结果依赖前面累计的状态。这是二者最本质的区别。4. 越用越容易翻车的几个边界条件4.1 最常见的翻车点回调里忘记 return说实话我 Review 过的代码里写reduce翻车最多的情况不是不知道 API而是箭头函数的简写体和函数体混用。看下面这段// 错误示范 const total orders.reduce((acc, order) { acc.amount order.amount; // 没有 return }, { amount: 0 });第一次回调返回undefined第二次acc就是undefined然后acc.amount直接抛TypeError。箭头函数如果用了花括号就必须显式return想简写就不加花括号。这个低级错误几乎每个前端都会遇到一次我自己的排查办法是写reduce回调时先默念一遍“我要 return 什么给下一轮”。提示如果你用 TypeScript遇到这类问题编译器会提示“Type undefined is not assignable to type”。保持返回类型一致是reduce回调最重要的一条纪律。4.2 返回值类型不一致第二次回调直接翻车很多人刚开始写reduce时会把返回值的类型随手改掉。比如想在一个对象里同时存数组和数字// 意图统计每个分类的数量和名称列表 const result items.reduce((acc, item) { if (!acc[item.category]) { acc[item.category] []; } acc[item.category].push(item.name); return acc; }, {});这个写法没毛病因为acc始终是那个外层对象。但如果哪一轮你写成了return acc[item.category]那下一轮的acc就变成了数组整个结构就散了。reduce的折叠逻辑要求每一轮返回的结构必须和初始结构兼容这是理解它的核心约束之一。4.3 空数组、稀疏数组与初始值的关系reduce对空数组的规则很严格不传初始值且数组为空时直接抛出TypeError: Reduce of empty array with no initial value。这在接口返回数据不确定时非常容易触发。假设后端偶尔返回[]你的代码就崩了。应对方法很简单要么无条件传初始值要么先判空。稀疏数组是另一个隐蔽的坑。JavaScript 中的稀疏数组比如new Array(5)或arr[1] 1但没有给索引 0 赋值在reduce遍历时会跳过那些空洞回调的执行次数会比数组长度少。如果你本以为回调会执行 5 次结果只执行了 2 次就可能出现诡异的结果。处理这种场景时建议先用Array.from把稀疏数组补齐再交给reduce。4.4 别在 reduce 里做有副作用的操作reduce的返回值机制适合做纯计算。如果你只是想遍历数组打日志、修改外部变量用forEach就好没必要用reduce。强行用reduce做副作用操作代码会变得拧巴而且容易因为返回值写错出 bug。// 不推荐 arr.reduce((_, item) { console.log(item); // 副作用 return undefined; }, undefined); // 推荐 arr.forEach((item) console.log(item));4.5 对同一个对象的引用共享用对象或数组做初始值时注意acc始终是同一个引用。这意味着如果你不小心修改了初始值对象它也会被同时修改。很多时候这不是问题甚至是我们要的效果。但如果你在多个地方复用了同一个初始值对象比如从 Redux 的全局状态里取出来的对象作为初始值那副作用就会被放大。安全做法是初始值用字面量新创建例如每次都写{}或[]避免复用外部引用。5. 放下执念正确选型比炫技更重要5.1 reduce 与其它数组方法的边界对比方法适合场景不适合场景map一对一转换返回和原数组等长的数组需要过滤、分组、累加filter按条件筛出子集需要改变元素结构find/findIndex提前终止查找第一个匹配项需要遍历全部数据并聚合forEach副作用操作不需要返回值需要返回值需要组装新结构reduce聚合、建表、分组、带状态扫描需要提前 break、简单遍历、纯副作用flat/flatMap扁平化和“展开一层后映射”需要深层次带条件扁平化这张表的判断标准其实只有一个你要的结果是不是由“多个元素折叠成一个值”如果回答是“是”reduce大概率合适。如果只是想“对每个元素做点事”用更专用的方法往往更清晰。5.2 什么时候应该果断放弃 reducereduce不是银弹。碰到下面情况我用它时都会重新掂量一是需要提前终止循环的时候。reduce没有内置的break也无法在中间退出它会老老实实跑完整个数组。要是要找第一个满足条件的元素find才是对的选择。二是可读性明显下降的时候。如果一个reduce回调超过十行或者嵌套了三层条件阅读成本就高了。代码评审时我看到这种“一坨大回调”第一反应通常不是点赞而是建议拆成普通函数或者拆成filtermap的多步管道。三是数据方向不是“从左往右”或者依赖索引顺序不强的场景。虽然reduce和reduceRight都支持但如果逻辑真的依赖倒序遍历直接用for循环从尾部开始往往更直观。5.3 在 TypeScript 中给 reduce 准确标注泛型reduce的 TypeScript 写法有个容易踩的坑如果初始值类型和最终结果类型不同你需要显式提供泛型参数否则 TS 会推断成初始值的类型后面想赋值别的类型就会报错。// 给泛型 Recordstring, number, number 标识累加器是对象当前值是数字 const countByCategory: Recordstring, number items.reduceRecordstring, number((acc, item) { acc[item.category] (acc[item.category] ?? 0) 1; return acc; }, {});这个细节在重构老项目时特别实用。你会注意到一旦把acc的类型写清楚reduce回调里“该返回什么”也就变得非常明确——大多数错误在编译期就被拦截了不用等到运行时炸。5.4 我的最终使用习惯写了几年reduce我逐渐总结出一套自己的判断方法先问这段逻辑是不是“把一组数据变成一个更浓缩的结果”。如果是就再看这个结果是否依赖之前累计的状态。两点都满足reduce就是最自然的表达。如果只是单个元素的变形用map只是筛选用filter需要提前退出或索引很强的逻辑就老实写for...of。工具原来就是挑着用的硬把所有数组操作都塞进reduce反而丢了它本来“归并”这个核心语义。最后分享一个排查技巧当reduce结果不对时别只盯着回调看先在脑子里把“上一轮返回了什么、这一轮收到的是什么”完整捋一遍。大多数 bug 都出在“我以为 acc 是那样实际上它是这样”的错位上。理解了这一点reduce就不再是面试题里的摆设而是你数组工具箱里最趁手的那把改锥。