17370845950

JavaScript数组高级操作核心是正确使用map、filter、reduce：reduce需严格匹配accumulator类型与初始值；map用于生成新数组，forEach仅用于副作用；filter须防御null/undefined；所有操作前应明确输入输出类型及边界情况。

JavaScript 数组的“高级操作”不是指冷门 API，而是 map、filter、reduce 这三个方法在真实场景中怎么用对、用稳、不掉坑。

为什么 reduce 总是写错初始值？

根本原因不是不会写逻辑，而是没想清楚 accumulator 的类型和初始值是否匹配。比如扁平化二维数组：arr.reduce((acc, cur) => acc.concat(cur), []) —— 这里 [] 是必须的，漏掉就会让第一次迭代的 acc 变成第一个子数组，后续 concat 就失效。

• 对象聚合时，初始值必须是 {}，不能是 null 或 undefined
• 求和/求积时，初始值用 0 或 1，但要注意空数组：若业务允许返回 0，就保留；否则得先 if (arr.length === 0) return defaultValue
• 链式调用前别直接 reduce，比如想先 filter 再 reduce，就分开写，别塞进一个 reduce 里硬扛逻辑

map 和 forEach 到底该选谁？

看要不要返回新数组。map 必须有返回值，且返回值会构成新数组；forEach 没返回值（返回 undefined），只适合副作用操作（如发请求、改 DOM、推入另一个数组）。

• 误用 map 做副作用：写了 arr.map(item => console.log(item))，结果得到一个全是 undefined 的数组，还占内存
• 误用 forEach 想转换数据：写了 arr.forEach(item => item * 2)，原数组没变，也没新数组，数据丢了
• 性能敏感场景（大数据量），for 循环比 map 略快，但可读性代价大，除非真测出瓶颈，否则别过早替换

用 filter

做条件筛选时，为什么结果比预期少？

常见于判断 null/undefined/NaN 或对象属性是否存在。例如：arr.filter(item => item.status === 'active')，如果某些 item 是 null，就会报 Cannot read property 'status' of null，整个 filter 中断并返回空数组（严格模式下）或抛错。

• 加防御： arr.filter(item => item && item.status === 'active')
• 更稳妥用可选链： arr.filter(item => item?.status === 'active')（注意 IE 不支持）
• 数值比较慎用 ==： filter(x => x.id == 123) 可能意外匹配字符串 '123'，统一用 ===
• filter(Boolean) 可以快速剔除假值，但会同时干掉 0、''、false，确认业务是否允许

真正难的不是记住每个方法签名，而是每次写之前问一句：我这次操作的输入类型、输出类型、边界情况（空、null、异步依赖）到底是什么。漏掉任意一环，高级操作就变成高级 Bug。