Object.entries + reduce 更适合结构重组，因其天然返回键值对数组、避免原型链污染、支持链式预处理，且累加器类型可控；但必须显式传入初始值（如{}或[]），否则单属性对象会直接返回数组而非预期结构。
Object.entries + reduce 为什么比 for...in 更适合结构重组
因为 Object.entries() 天然返回键值对数组，直接进入 reduce() 流程，避免手动取 key 再查 value 的重复操作；而 for...in 会遍历原型链、需额外 hasOwnProperty 判断，且无法链式处理（比如过滤、映射后再聚合）。
常见错误是误以为 Object.entries(obj) 返回的是对象——它返回的是二维数组，必须用解构 [key, value] 拿值，否则直接展开会出错。
- 只处理自身可枚举属性，不污染原型链
- 配合
map/filter预处理更灵活（例如跳过某些字段） - 返回数组后，
reduce的累加器类型完全可控（比如始终是对象、或始终是数组）
重组为新对象：必须传 {} 作 reduce 初始值
漏掉 initialValue 是最常踩的坑。当输入对象只有一个键（如 {name: 'Alice'}），Object.entries().reduce(callback) 会把 ['name', 'Alice'] 当作第一个参数传给 callback，而不是执行你写的逻辑——结果是返回这个数组，不是对象。
正确写法必须显式传空对象：
const result = Object.entries(source).reduce((acc, [key, value]) => {
acc[key.toUpperCase()] = typeof value === 'string' ? value.trim() : value;
return acc;
}, {}); // ← 这里不能省
- 空对象
{}作为初始值，保证 acc 始终是对象 - 不要在回调里用
return {...acc, [newKey]: newValue}—— 对大对象性能差，且每次新建对象 - 若需深拷贝再修改，应先 clone 再赋值，而非靠展开运算符“假装安全”
重组为数组：用 reduce 替代 map 的真实理由
当你要的不是“一一对应”，而是“条件聚合”或“结构降维”，reduce 比 map 更直接。比如把对象按 value 类型分组、合并同名数组、或只提取满足条件的键值对并转成扁平数组。
示例：把对象中所有字符串值提取出来，组成一个去重数组：
const strings = Object.entries(obj).reduce((arr, [_, value]) => {
if (typeof value === 'string' && !arr.includes(value)) {
arr.push(value);
}
return arr;
}, []);
- 用
map得先全量映射再filter+flat+Set，步骤多且中间数组浪费内存 -
reduce可边遍历边判断、边去重，逻辑集中 - 注意：初始值用
[]，不是''或null，否则类型错乱
嵌套对象递归重组时，reduce 容易忽略的 null 判断
typeof null === 'object' 是 JS 硬伤。如果输入数据可能含 null（比如后端字段未填），直接用 typeof value === 'object' 会把 null 当对象递归，导致后续报 Cannot convert undefined or null to object。
安全写法要显式排除：
function deepTransform(obj) {
if (obj === null || typeof obj !== 'object') return obj;
return Object.entries(obj).reduce((acc, [key, value]) => {
acc[key] = (value === null || typeof value !== 'object')
? value
: { update: deepTransform(value) };
return acc;
}, {});
}
- 顶层判空必须放最前，否则递归进
null就崩 - 数组也属于
typeof === 'object'，如需区分对象和数组，用Array.isArray(value) - 如果业务明确不含
null，可省略，但上线前务必确认 API 文档是否承诺非空
reduce 不会自动帮你“猜”要什么类型，传错 initialValue 导致整个流程静默失败，比报错更难排查。 
