Object.entries 比 for...in 更适合配置转换，因其只遍历自身可枚举属性、返回规范键值对数组，天然适配 reduce；但需注意数字/Symbol 键处理、Map 初始化及性能优化。
Object.entries 为什么比 for...in 更适合做配置转换
因为 for...in 会遍历原型链上的可枚举属性，而配置对象常来自 JSON 或服务端响应，没有原型污染风险但结构松散——Object.entries 只取自身可枚举键值对，返回确定的 [key, value] 数组，天然适配 reduce 的累加器输入格式。
常见错误是直接对原始对象调用 reduce：JavaScript 对象不能直接被 reduce，必须先转成数组。漏掉这步会报 TypeError: obj.reduce is not a function。
用 reduce 构建 Map 时必须传入 new Map() 作为初始值
reduce 的第二个参数（初始值）不能省略或传空对象，否则第一次迭代时 acc.set 会失败——因为普通对象没有 set 方法。Map 是唯一原生支持键值对映射且保留插入顺序的数据结构，比 {} 更适合做运行时配置索引。
实操建议：
- 始终把
new Map()作为reduce的第二个参数 - 回调函数中用
acc.set(key, value)，不要写acc[key] = value - 如果 value 是嵌套对象，需判断是否需要深拷贝；多数配置场景浅赋值即可
遇到非字符串 key 时 Object.entries 会自动 toString
原始配置若含 Symbol 或数字 key（如 { 123: 'abc', [Symbol('x')]: 'y' }），Object.entries 会把数字转成字符串、忽略 Symbol 键——这是 JavaScript 规范行为，不是 bug。如果你的配置依赖 Symbol 作为唯一标识，就不能走 Object.entries 这条路，得改用 Reflect.ownKeys + map + reduce 组合。
示例对比：
const cfg = { 42: 'answer', true: 'yes' };
console.log(Object.entries(cfg)); // [['42', 'answer'], ['true', 'yes']] —— 数字和布尔都被转字符串了
性能敏感场景下注意 reduce 的中间数组开销
当配置项超过几千条时，Object.entries(obj) 会生成一个新数组，再由 reduce 遍历——内存多一次分配，时间多一次循环。此时更高效的做法是用 for...of 配合 Object.entries 的迭代器：
const map = new Map();
for (const [k, v] of Object.entries(cfg)) {
map.set(k, v);
}
它不生成中间数组，V8 引擎也更容易优化。只有当你需要链式处理（比如 entries → filter → reduce）时，才值得为可读性接受那点开销。
真正容易被忽略的是：Map 的 key 是严格相等比较（===），如果原始配置里有 '1' 和 1 两个 key，它们在 Map 中会共存；但经过 Object.entries 后，数字 key 已变成字符串，另一方就没了。这点在对接后端返回混合类型 key 的配置时特别关键。
