reduce累加数字时必须显式传入初始值0，否则空数组报错或触发nan；字符串拼接应传''；对象去重需用some而非includes；避免push修改原数组，改用展开语法；嵌套reduce优先用flat/flatmap替代。
reduce 累加数字时，初始值必须显式传入 0
不传 initialValue 会导致空数组报错，或非数字类型被强制转为 NaN。比如 [1, 2, 3].reduce((a, b) => a + b) 在数组为空时直接抛 TypeError: Reduce of empty array with no initial value。
实操建议：
- 始终显式传入
0（数字累加）或''（字符串拼接），避免隐式类型转换陷阱 - 如果数组元素是字符串数字（如
['1', '2', '3']），先用Number()或一元加号+b转换，否则'1' + 2得到'12' - 遇到嵌套结构（如
items.map(x => x.price)）建议先提取再 reduce，别在 reducer 函数里做 map 逻辑
用 reduce 去重要注意对象引用和原始值的区别
对原始值（string/number/boolean）去重，可以用 Array.from(new Set(arr)) 更简洁；但 reduce 的优势在于能按需定制逻辑，比如去重同时保留最后一次出现的项，或基于某个 key 去重对象数组。
常见错误：直接用 acc.includes(item) 判断对象是否已存在——这比的是引用，不是内容。
实操建议：
- 对对象数组去重，用
acc.some(x => x.id === item.id)替代includes - 想保留首次出现项，用
!acc.some(...)；想保留末次，把item放前面：[item, ...acc.filter(x => x.id !== item.id)] - 性能敏感场景慎用
some/filter嵌套——每轮都要遍历整个acc，O(n²)，大数据量改用Map或预建索引
reduce 转换数据结构时，别在累加器里 push，要返回新数组
reduce 要求每次回调都返回下一个累加器值。写成 acc.push(item); return acc 看似可行，但会污染原数组、破坏函数式习惯，且后续操作容易出错（比如多次调用后 acc 是同一个引用）。
典型错误示例：arr.reduce((acc, x) => { acc.push(x * 2); return acc; }, []) —— 这个 acc 是同一个数组实例，虽结果正确，但副作用明显。
实操建议：
- 统一用展开语法：
[...acc, x * 2]或acc.concat(x * 2) - 转换为对象时，用
{ ...acc, [x.id]: x }，注意 key 冲突会覆盖 - 需要分组（如按 status 归类），初始化为
{}，然后{ ...acc, [x.status]: [...(acc[x.status] || []), x] }
嵌套 reduce 容易失控，优先考虑 flatMap + reduce 或分步处理
看到 arr.reduce((a, b) => b.items.reduce(...)) 这类写法，基本意味着可读性和调试难度已经上升。深层嵌套不仅难定位 bug，还掩盖了“先展平再聚合”的真实意图。
实操建议：
- 二维数组扁平化累加？先用
arr.flat().reduce(...)，比双层 reduce 清晰得多 - 需要边展平边过滤？用
arr.flatMap(x => x.items).filter(...).reduce(...) - 真要嵌套（比如树形结构递归聚合），把内层逻辑抽成独立函数，命名体现语义，如
sumSubItems(node)
最常被忽略的一点：reduce 本身不关心数据形状，但它暴露了你对数据流的理解程度——写得越绕，往往说明结构没理清，或者过早优化了。
