Object.fromEntries 不清理空值，需先用 Object.entries 拆解、filter 筛选（如 v != null && v !== ''）、再 fromEntries 组装；0 和 false 是否剔除取决于业务需求，非技术默认行为。
Object.fromEntries 本身不清理空值，得配合 filter
Object.fromEntries 只负责把键值对数组转成对象，它不会主动过滤任何东西。想“清理空值”，本质是先用 Object.entries 拆出数组，再用 filter 筛掉空值项，最后才交给 Object.fromEntries 组装回去。
常见空值判断场景包括：null、undefined、空字符串 ''、NaN，有时也包括 0 或 false——但要注意：是否剔除 0 和 false 是业务决定的，不是技术默认行为。
实操建议：
- 用
Object.entries(obj)获取[key, value]数组 - 用
.filter(([k, v]) => v != null && v !== '')做基础空值过滤（!= null同时排除null和undefined） - 避免直接写
v做真值判断，否则会误删0、false、''（而''已被显式排除，但0和false可能是合法值）
为什么不用 Object.keys + reduce 或 for...in？
有人习惯用 Object.keys(obj).reduce 构建新对象，或用 for...in 遍历后手动赋值。这两种方式在语义和可读性上不如 fromEntries + filter 直观——前者聚焦“从条目出发”，后者更像“逐个检查再拼装”，容易漏掉 hasOwnProperty 判断或原型污染风险。
性能方面差异极小，现代引擎对 Object.entries + filter + fromEntries 的链式调用优化得很好；真正影响性能的是对象大小和过滤逻辑复杂度，不是方法选型。
实操建议：
- 坚持用
Object.entries而非for...in，天然跳过原型链属性 - 避免在
reduce中反复新建对象（如{...acc, [k]: v}），尤其对大对象，会产生大量中间对象 - 如果需兼容 IE，
Object.fromEntries不可用，此时应退回到Object.assign(...entries.map(...))或用 polyfill
处理嵌套对象或数组里的空值？fromEntries 不管这事
Object.fromEntries 只作用于顶层键值对。如果对象里有嵌套结构（比如 user: { name: '', profile: { age: null } }），它完全无感。这时候清理空值属于深过滤问题，必须递归或用专门工具函数。
一个常见误区是以为加个 JSON.stringify → JSON.parse 就能“深层清理”，其实不能——JSON 会丢掉 undefined、函数、Symbol，且无法控制哪些空值该留哪些该删。
实操建议：
- 明确需求层级：只清顶层？还是所有字符串字段为空就删？还是仅删
null/undefined但保留空字符串？ - 若需深层清理，单独封装函数，不要硬塞进
fromEntries流程里 - 考虑用
lodash.omitBy配合自定义谓词，比手写递归更稳
空值判定逻辑要提前约定，别等上线才发现 0 被删了
最常踩的坑是开发时按“空即删”直觉写 v 判断，结果测试发现用户年龄 0、开关状态 false 全没了。这不是 fromEntries 的错，而是空值定义模糊导致的。
实操建议：
- 在项目公共工具函数里统一空值过滤逻辑，比如叫
omitEmpty，并注释清楚它剔除哪些值 - 接口请求前清理数据时，优先用字段白名单（
pick）而非黑名单（omit），更安全 - 对必填字段做校验，而不是依赖“清理”来掩盖缺失
真正难的从来不是怎么写这一行 Object.fromEntries，而是搞清“谁算空”“在哪一层空”“空了之后下游能不能接住”。
