不提供初始值调用 reduce() 会以首元素为初始值并从第二项开始遍历，但存在三类隐患：空数组抛 typeerror；单元素数组不执行 reducer；首元素类型与后续逻辑不匹配（如字符串数组求平均长度时初始值为字符串导致拼接错误）。
当调用 reduce() 且未提供初始值时，它会自动将数组第一个元素作为累加器的初始值，并从第二个元素开始遍历。这种隐式行为看似方便，实则埋下三类典型隐患：空数组报错、单元素数组跳过回调、以及首元素类型与后续逻辑不匹配。
空数组直接抛出 TypeError
若数组为空，reduce() 找不到“首个元素”作为初始值，会立即抛出 TypeError: Reduce of empty array with no initial value。这在动态数据场景中极易触发未捕获错误。
- ✅ 建议：对可能为空的数组，显式传入初始值（如
0、''或null） - ✅ 或提前校验：
arr.length === 0 ? defaultValue : arr.reduce(...)
单元素数组完全不执行 reducer 函数
例如 [42].reduce((a, b) => a + b) 直接返回 42，内部回调一次都不运行。若你的逻辑依赖回调中的副作用（如日志、状态更新、类型转换），就会静默失效。
- ✅ 若需强制执行逻辑，统一提供初始值（哪怕和首元素同值），确保回调至少调用一次
- ✅ 或改用
reduceRight()/ 循环等更可控方式，避免依赖隐式行为
首元素被当作“初始值”，但类型或语义不符
常见于混合类型或需要预处理的场景。比如计算字符串数组平均长度：['a', 'bb', 'ccc'].reduce((sum, str) => sum + str.length)。虽然结果正确，但 sum 初始是字符串 'a'，首次调用实际执行的是 'a' + 'bb'.length → 'a2'，后续变成字符串拼接而非数字累加，最终结果为 'a23' 而非 6。
- ✅ 根本解法：始终提供明确初始值，如
0，让累加器类型从一开始就确定 - ✅ 避免依赖“首元素合理”的假设，尤其在数据结构不确定时
不提供初始值的 reduce 是一种隐式契约，而契约一旦被数据打破，错误就难以定位。显式优于隐式，安全优于简洁。
