我在 JavaScript 里用 reduce 求和写得简洁又顺手、测试也全过,上线后却突然抛出 Reduce of empty array with no initial value 把页面整个搞崩,我盯着那行用了无数次的 reduce 百思不得其解,最后才明白只要传进来的是个空数组、而我又没给它一个初始值,reduce 就会因为根本没有起点可用而直接报错

这是一次让我把 JavaScript 里"reduce 的初始值"这件事,从"可有可无的第二个参数",重新理解成"归约的起点、也是处理空集合边界的关键"的事故。我用 reduce 求和,写得简洁又顺手,测试也全过。上线后却突然抛出 TypeError: Reduce of empty array with no initial value,把页面整个搞崩。我盯着那行用了无数次的 reduce 百思不得其解,最后才明白:只要传进来的是个空数组、而我又没给它一个初始值,reduce 就会因为根本没有起点可用而直接报错。这篇就把这次"空数组 reduce 崩页面"的事故,从头到尾复盘一遍。

故障现场:平时好好的 reduce,遇到空数组就崩

我有段代码,要把一个数组里的数字求和(或把一批对象的某个字段累加),很自然地写成 items.reduce((sum, item) => sum + item.amount)。本地测、写单测,传的都是有数据的数组,一切正常,结果也对。我对这行代码很放心,上线了。

可线上某个场景下,items 是个空数组(比如用户没有任何订单、筛选后没有结果)。这一下,整个页面崩了,控制台一行刺眼的 TypeError: Reduce of empty array with no initial value。我当时很懵:reduce 我用过无数次,怎么会报错? 我反复看那行代码,逻辑没毛病。直到我去查 reduce 的规范,才彻底明白根因——reduce 在不传第二个参数(初始值)时,会拿数组的第一个元素当作初始的累加值、然后从第二个元素开始迭代。这套机制依赖一个隐含前提:数组至少有一个元素(好让它有第一个元素当起点)。可一旦数组是空的,它既没有"第一个元素"当起点、我又没给它一个初始值,reduce 就无从开始——没有任何可作为起点的东西,于是它不沉默地返回个什么(那也容易出错),而是直接抛出 TypeError。我那行代码,在数组非空时一切正常,恰恰是因为它一直有"第一个元素"兜底;而我从没想过"空数组"这个边界,会让这个隐含的起点消失。

// 我的写法: reduce 求和, 没传初始值
const total = items.reduce((sum, item) => sum + item.amount);

// 数组有元素时正常:
[{amount:1},{amount:2},{amount:3}].reduce((s,i)=>s+i.amount);  // 用第一个当起点, OK

// 数组为空时直接崩:
[].reduce((s,i)=>s+i.amount);
// ✗ TypeError: Reduce of empty array with no initial value

// 原因: reduce 不传初始值时, 拿【第一个元素】当初始累加值、从第二个开始迭代;
//   这依赖"数组至少有一个元素"。空数组既没第一个元素当起点、又没给初始值,
//   reduce 无从开始 → 直接抛 TypeError。

// 还有个隐蔽问题: 单元素数组不传初始值, 回调【一次都不执行】
[{amount:5}].reduce((s,i)=>s+i.amount);
// 返回 {amount:5} 这个对象本身(直接当结果), 而不是 5! 类型都错了

问题被钉死在这个认知错位上:我以为 reduce 的第二个参数(初始值)是"可有可无的优化",但它其实是归约的"起点";不给它,reduce 就只能借用数组的第一个元素当起点——而这要求数组至少有一个元素。空数组打破了这个前提:既没有第一个元素、又没有我给的初始值,reduce 就彻底没了起点、只能报错。更隐蔽的是,即便数组只有一个元素,不传初始值时回调一次都不会执行,reduce 直接把那个元素当结果返回——如果我期望的结果类型(数字)和元素类型(对象)不一样,这里就会悄悄返回一个类型都不对的东西。我一直在"非空数组"这个舒适区里用 reduce,从没意识到它对"空"和"单元素"这两个边界,有着如此脆弱的依赖。我以为 reduce 总能从数组里自己找到起点,却忘了空数组里,连一个可借的起点都没有。

第一件事:想明白初始值是"归约的起点与空集合的兜底"

把这次事故彻底想清楚,关键是理解reduce(callback, initialValue) 的初始值,本质是"归约的起点"——归约就是"从一个起点开始,把元素一个个并入累加器"的过程。给了初始值,reduce 就从这个初始值开始、把每一个元素(包括第一个)都并进来;不给初始值,reduce 就借用第一个元素当起点、从第二个元素开始并入。所以:传了初始值,空数组安然返回这个初始值(归约零个元素,结果就是起点本身);不传初始值,空数组无起点可借,直接报错。

这个"起点",在数学上对应"单位元"(求和的单位元是 0、求积是 1、拼接数组是 []、合并对象是 {}):给归约一个正确的单位元作初始值,既让"空集合"这个边界有了天然、正确的结果(空集合归约 = 单位元),又让累加器的类型从一开始就明确(而不是被第一个元素的类型偶然决定)。所以最佳实践非常简单:给 reduce 永远传一个类型正确的初始值。这一个小小的参数,同时解决了两个问题——空数组不再崩(返回初始值)、单元素数组也会正确调用回调(从初始值开始并入那个元素、类型正确)。关键认知是:任何"从一组元素归约出一个结果"的操作,都应当显式提供一个"起点/单位元",而不是依赖"集合里一定有至少一个元素可以借来当起点"这个会被空集合打破的隐含假设。

// 正解: 永远给 reduce 传一个类型正确的初始值(单位元)

// 求和: 初始值 0
const total = items.reduce((sum, item) => sum + item.amount, 0);
[].reduce((s, i) => s + i.amount, 0);          // ✓ 返回 0, 不崩

// 求积: 初始值 1
const product = nums.reduce((p, n) => p * n, 1);

// 拼数组: 初始值 []
const flat = arrs.reduce((acc, a) => acc.concat(a), []);

// 合并对象/计数: 初始值 {}
const countByType = items.reduce((acc, it) => {
    acc[it.type] = (acc[it.type] || 0) + 1;
    return acc;
}, {});                                         // ✓ 空数组返回 {}

// 单元素数组也正确: 从初始值开始并入那个元素, 回调会执行、类型正确
[{amount: 5}].reduce((s, i) => s + i.amount, 0); // 5 (而不是 {amount:5})

// 对比: 不传初始值的隐患(空崩 / 单元素不调回调 / 累加器类型由首元素定)
// items.reduce((s, i) => s + i.amount);  // ✗ 别这么写

想通这一层,我才明白自己错在哪:我把 reduce 的初始值当成了"不写也行的可选项",而没意识到它是归约的"起点"——没有它,reduce 就得去数组里借第一个元素当起点,而空数组里根本没有可借的。我的测试里数组总是非空,这个"借来的起点"一直存在,问题就被掩盖了;直到线上来了个空数组,这个借不到的起点,就让 reduce 当场崩溃。根治之道简单到只是一个参数:永远给 reduce 传一个类型正确的初始值(单位元),让空集合有正确的结果、让累加器类型从一开始就确定。不是指望集合里总有元素可以当起点,而是主动为归约提供一个不依赖集合是否为空的、确定的起点。

第二件事:正解——永远传类型正确的初始值,并显式处理空集合

找到根因,正解就清晰了:给 reduce 永远传一个类型正确的初始值(单位元)——求和传 0、求积传 1、拼数组传 []、合并对象传 {};这样空数组安然返回初始值、单元素数组也会正确调用回调、累加器类型从一开始就确定。如果"空集合"本身需要特殊处理(比如显示"暂无数据"),就在 reduce 之外显式判断空、给出对应的业务结果。

// 错误: 不传初始值, 空数组崩、单元素不调回调
const total = items.reduce((s, i) => s + i.amount);           // ✗

// 正解1: 传类型正确的初始值(单位元)
const total = items.reduce((s, i) => s + i.amount, 0);        // ✓ 空数组得 0

// 正解2: 空集合需要业务上的特殊结果时, 在 reduce 外显式判空
function summarize(items) {
    if (items.length === 0) {
        return { total: 0, empty: true };       // 明确给出"空"的业务语义
    }
    const total = items.reduce((s, i) => s + i.amount, 0);
    return { total, empty: false };
}

// 正解3: 不只是 reduce —— 其他"从元素里取一个"的操作也要防空
const max = nums.length ? Math.max(...nums) : 0;   // Math.max() 空时是 -Infinity
const first = list.at(0);                           // 空数组得 undefined, 要判
const [head] = list;                               // 解构同理, 空时 head 是 undefined

// 经验法则: 任何"把一组元素归约/聚合成一个结果"的地方, 都问一句:
//   "如果这组元素是空的, 结果应该是什么?" 并显式提供那个结果(单位元/兜底)。

这套做法的精髓,是为"归约"显式提供一个不依赖集合是否为空的"起点",并把"空集合"当成一个必须被想到、被处理的正常边界,而不是一个会让代码崩溃的意外。给 reduce 传单位元,一行就同时解决了"空数组崩""单元素不调回调""累加器类型不定"三个问题;而当"空"有特殊业务含义时,在 reduce 之外显式判空、给出对应结果,让"没有数据"这件事得到体面的处理。不是假设集合里总有元素,而是先想清楚"集合为空时结果应该是什么",并主动把那个结果提供出来。

【用 reduce / 聚合操作, 我现在认死的几条】

1. reduce 不传初始值: 借第一个元素当起点、从第二个开始迭代

2. 空数组 + 不传初始值 → TypeError(无起点可借), 直接崩

3. 单元素 + 不传初始值 → 回调一次不执行, 直接返回那个元素(类型可能错)

4. 永远给 reduce 传类型正确的初始值(单位元): 和 0/积 1/数组 []/对象 {}

5. 空集合有业务含义时, 在 reduce 外显式判空、给对应结果

6. Math.max/min、at(0)、解构取首元素等, 对空集合也要防(返回 -Inf/undefined)

7. 任何聚合都先问: "集合为空时, 结果应该是什么?" 并显式提供它

第三件事:其他"依赖集合非空、对空边界没兜底"的同类坑

顺着"操作隐含假设集合至少有一个元素、对空集合没兜底"这条线,我把同类的坑都排查了一遍:

第一个,Math.max/min 对空数组返回 -Infinity/Infinity。Math.max(...[]) 是 -Infinity,你拿去比较/显示就会出怪结果;要先判空。

第二个,取首元素/末元素不判空。arr[0]、arr.at(-1) 在空数组上是 undefined,直接 .xxx 就 "Cannot read properties of undefined"。

第三个,除以"个数"算平均值,个数为 0 时除零得 NaN。sum / arr.length 在空数组上是 0/0 = NaN,要先判空或给默认。

第四个,SQL 的聚合/MAX 在没有行时返回 NULL。SELECT MAX(x) 没有匹配行时是 NULL,程序按数字用就出错;同样是"空集合的归约"没兜底。

第四件事:传初始值 vs 不传——一张对照表

我把 reduce 传不传初始值的行为摆在一起对比,核心看"空数组、单元素、累加器类型三种情况":

看清这张表,结论就毫无悬念了:永远给 reduce 传一个类型正确的初始值——它让空数组返回单位元而非崩溃、让单元素也正确调回调、让累加器类型从一开始就确定;不传只在"数组非空且累加器类型恰好等于元素类型"时才侥幸没事。我这次踩坑,正是栽在"不传初始值 + 线上来了空数组"上。一个小小的初始值参数,是 reduce 的安全底座。

第五件事:我曾经对 reduce 想当然的几个误区

这次事故也把我对 reduce 的一堆"想当然"照了个底朝天:

这些误区的根子是同一个:我把"从一组元素里归约出结果"默认成了"这组元素里总有元素可用",从而省掉了那个本该提供的"起点",也没把"空集合"当成一个必须处理的边界。归约这件事,逻辑上需要一个独立于"有没有元素"的起点(单位元);我没给它,就等于把起点的供给,寄托在"集合恰好非空"这个我控制不了的运气上。把"集合总有元素"当成理所当然、不为"空"这个边界提供起点和兜底,是这类聚合崩溃的共同根源。

第六件事:写 reduce/聚合、排查"空集合崩"时,我现在的自检习惯

现在每当我写 reduce 或任何聚合操作、或排查"遇到空数据就崩",我都会先按这张图问自己:

这张图的精髓,是"归约要显式提供起点/单位元、把空集合当必须处理的边界;给 reduce 永远传类型正确的初始值"。设计就给 reduce 传单位元、聚合前先想清楚空集合的结果、空有业务含义就显式判空、排查就看是不是空集合让 reduce 借不到起点或让 max/取首元素得了怪值。这套习惯,让我从"reduce 不传初始值图简洁"变成了"永远先给归约一个起点"——核心始终是:reduce(callback, initialValue) 的初始值本质是归约的起点——归约就是从一个起点开始把元素一个个并入累加器的过程:给了初始值 reduce 就从这个初始值开始把每一个元素(包括第一个)都并进来,不给初始值 reduce 就借用第一个元素当起点、从第二个元素开始并入;所以传了初始值空数组安然返回这个初始值(归约零个元素结果就是起点本身)、不传初始值空数组无起点可借直接报 TypeError,而且不传初始值时单元素数组的回调一次都不执行、直接把那个元素当结果返回(若期望结果类型和元素类型不一样这里就悄悄返回类型都不对的东西);这个起点在数学上对应单位元(求和 0、求积 1、拼数组 []、合并对象 {}),给归约一个正确的单位元作初始值既让空集合这个边界有了天然正确的结果(空集合归约=单位元)又让累加器类型从一开始就明确;最佳实践就是给 reduce 永远传一个类型正确的初始值——这一个小参数同时解决空数组不再崩、单元素也正确调回调、累加器类型确定三个问题;更一般地,任何从一组元素归约出一个结果的操作都应当显式提供一个起点/单位元、而不是依赖集合里一定有至少一个元素可以借来当起点这个会被空集合打破的隐含假设,Math.max/min、取首末元素、除以个数算平均、SQL 的 MAX 等聚合对空集合同样要兜底。

我立下的几条规矩

这场"空数组 reduce 崩页面"的事故,换来了我写聚合时,刻进骨子里的几条铁律:

1. reduce 不传初始值会借第一个元素当起点,空数组无起点可借直接崩。
2. 不传初始值时单元素数组回调一次不执行,直接返回该元素(类型可能错)。
3. 永远给 reduce 传类型正确的初始值(单位元):和 0/积 1/数组 []/对象 {}。
4. 空集合有业务含义时,在 reduce 外显式判空、给对应结果。
5. Math.max/min、取首末元素、除以个数,对空集合也要防(-Inf/undefined/NaN)。
6. 任何聚合都先问:"集合为空时,结果应该是什么?"并显式提供它。
7. 测试要专门覆盖空集合这个边界,别只在非空舒适区里测。

附:我现在写聚合的"带单位元的安全归约"工具

这是我现在写聚合固定套的工具——把这次踩坑的教训(永远带单位元、显式处理空集合)固化成几个小函数,让"空数组 reduce 崩"那种坑再不会埋进代码:

// 工具1: 安全求和/求积 —— 内置正确的单位元, 空数组返回单位元而非崩
const sumBy = (arr, fn) => arr.reduce((s, x) => s + fn(x), 0);   // 单位元 0
const productBy = (arr, fn) => arr.reduce((p, x) => p * fn(x), 1); // 单位元 1

sumBy([], x => x.amount);                 // ✓ 0, 不崩
sumBy([{amount: 5}], x => x.amount);      // ✓ 5, 类型正确

// 工具2: 安全求最值 —— 显式处理空集合, 别让 Math.max 返回 -Infinity
function maxBy(arr, fn, fallback = null) {
    if (arr.length === 0) return fallback;   // 空集合给明确兜底
    return arr.reduce((best, x) => (fn(x) > fn(best) ? x : best));
    // 此处非空, reduce 借首元素当起点是安全的(且都是同类型元素)
}

// 工具3: 安全平均值 —— 防除零
const average = arr => (arr.length ? sumBy(arr, x => x) / arr.length : 0);

// 工具4: 通用分组计数 —— 单位元 {}, 空数组返回 {}
function countBy(arr, keyFn) {
    return arr.reduce((acc, x) => {
        const k = keyFn(x);
        acc[k] = (acc[k] || 0) + 1;
        return acc;
    }, {});                                  // ✓ 空数组返回 {}
}

// 自检: 每个聚合都用空数组测一遍, 确认不崩、返回的是正确的单位元
console.assert(sumBy([], x => x) === 0);
console.assert(Object.keys(countBy([], x => x)).length === 0);
console.assert(maxBy([], x => x, "无数据") === "无数据");

这套工具把我这次的教训钉死在了代码里:求和求积等内置正确的单位元(0/1)、空数组安然返回单位元;求最值/平均等"真需要非空"的操作显式判空给明确兜底(别让 Math.max 返回 -Infinity、别除零得 NaN);分组计数用 {} 作单位元;并用空数组断言验证每个聚合都不崩、返回正确的空结果。这样,无论传进来的集合是满的还是空的,聚合都能给出正确的结果,而不再是当初那个"非空时好好的、一遇空数组就崩页面"的局面。把"聚合要先想清楚空的时候怎么办、并主动提供独立的起点"这个道理,沉淀成写聚合的固定工具,这是我对这次"空数组崩页面"最实在的交代——毕竟,一个连"什么都没有"都能从容应对的聚合,才算真的写对了。

写在最后

回头看,这场由"reduce 没传初始值"引发的"空数组崩页面"事故,真正教给我的,远不止"给 reduce 加个 0"这一个技巧。它让我对"当我们要'从一组东西里归纳/聚合出一个结果'时,这个过程其实需要一个独立于'这组东西本身'的'起点'——一个'当这组东西一个都没有时,结果就是它'的基准;我们常常图省事,让过程'从这组东西里随便借一个当起点',这在'东西不为空'时天衣无缝,却在'一个都没有'的边界上彻底失灵,因为连个可借的起点都没有了",有了一次刻骨的体会。我栽跟头,是因为我把"归约的起点"这件本该独立提供的事,偷懒地寄托在了"集合里总有第一个元素可以借"上——我写 reduce 时只想着"把元素一个个加起来",默认总有元素可加、总有第一个可以当起点;我从没认真想过"如果一个元素都没有呢?这时候'加起来'该从哪开始、结果又该是什么?";而正是这个我从没想过的"空"的边界,在线上某个平凡的时刻悄然到来——一个没有订单的用户、一个筛选后为空的列表——让我那个"借来的起点"凭空消失,reduce 当场崩溃。这让我领悟到一个关于"聚合、起点与空边界"的深刻认知:任何"把多个归并成一个"的操作(求和、求最值、合并、拼接、统计),在逻辑上都需要一个"零元素时的结果"——也就是一个独立于具体元素的"起点/单位元";这个起点不该从"集合里借",而该被我们明确地、独立地提供,因为只有它能回答"当集合为空时,结果是什么"这个边界问题;而"空"恰恰是最容易被忽略、却又一定会到来的边界:开发和测试时我们手里总有数据,于是一直活在"非空"的舒适区里,那个借来的起点一直兜着底,直到真实世界送来一个空集合,缺了独立起点的代码才暴露出它从一开始就有的脆弱;真正稳健的聚合,是从设计之初就回答"空的时候怎么办"、并主动提供那个不依赖元素是否存在的起点,而不是赌"总会有元素"。这给了我一种看待"一切'把一组东西归约成一个'之事"时的清醒:每当我要把一组元素聚合/归纳成一个结果时,要追问"如果这组元素一个都没有,结果应该是什么?我有没有为这个'空'的情况,提供一个独立于元素的、明确的起点或兜底"——为归约显式提供一个不依赖集合是否为空的起点(单位元),把'空集合'当成必须想到并处理的正常边界,而不是赌它不会发生;"聚合要先想清楚空的时候怎么办、并主动提供独立的起点",是用对 reduce、也是写出健壮聚合逻辑的关键。认清 reduce 初始值是归约的起点、空数组无起点可借会崩、永远传类型正确的单位元——这,是我用一次"空数组 reduce 崩了线上页面"的事故,换来的、关于 JavaScript、也关于如何为聚合提供起点与处理空边界的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次写 arr.reduce(...) 时,顺手补上那个初始值、并多想一句"arr 要是空的呢?",那我对着那个"Reduce of empty array"崩掉的线上页面排查的那阵子,就值了。

—— 别看了 · 2026