Lodash 集合操作怎么选？map、filter、groupBy 的实际用法是什么？

Lodash 的集合方法适合处理“接口给了一堆数组或对象，我要筛、转、分组、排序、统计”的场景。它的好处不是把原生 JS 全部替掉，而是把常见数据处理动作写得更短、更稳定，尤其是对象路径、空值、分组统计这些边界比较多的地方。日常项目里可以先记住一条取舍：简单数组转换优先用原生 map/filter/reduce，涉及对象集合、链式处理或兼容老代码时再用 Lodash。

常用集合方法怎么分工？

_.forEach 负责遍历，返回 false 可以提前中断；如果只是为了生成新数组，不要用它硬塞 push，_.map 更清楚。_.filter 保留符合条件的数据，_.reject 做相反的事，二者都支持函数、对象、数组路径和属性名这些 shorthand 写法。_.find 找第一个命中的元素，适合查配置、查用户、查枚举；如果要全部结果，才用 filter。

_.groupBy、_.keyBy 和 _.countBy 更像三种整理方式。groupBy 把一组数据按字段分桶，适合订单按状态、日志按日期归类；keyBy 把数组转成以某个字段为 key 的对象，适合后续 O(1) 查询；countBy 只关心数量，适合做简单统计。它们的踩坑点在于 key 会被转成字符串，true、1、'1' 混在一起时要先规范数据。

javascript
import _ from 'lodash';

const orders = [
  { id: 1, user: 'A', status: 'paid', amount: 120 },
  { id: 2, user: 'B', status: 'pending', amount: 80 },
  { id: 3, user: 'A', status: 'paid', amount: 60 }
];

const paidByUser = _.chain(orders)
  .filter({ status: 'paid' })
  .groupBy('user')
  .mapValues(list => _.sumBy(list, 'amount'))
  .value();

console.log(paidByUser); // { A: 180 }

什么时候适合链式调用？

链式调用适合“连续做三步以上”的数据管道，比如先过滤、再分组、再汇总。它让中间变量变少，也让业务意图从上到下排列，代码评审时更容易看出每一步在干什么。但链式调用不是越长越好，超过五六步后可读性会下降，尤其是 mapValues、flatMap、orderBy 混在一起时，建议拆出命名函数。

性能上也要有边界感。Lodash 的惰性求值只覆盖部分链式数组方法，不要默认以为所有链都只遍历一次。大数据量列表，比如几万条日志，在浏览器里处理前最好先确认是否能分页、下推到后端，或者至少用 take 限制结果量。

对象集合也能处理，但要先确认输出形态

很多人以为集合方法只服务数组，其实 Lodash 把对象也当集合处理。_.forOwn 更适合遍历对象自身属性，_.mapValues 能保留 key 并转换 value，_.pickBy 可以按条件筛掉不需要的字段。这个能力在处理配置对象时很好用，比如只保留开启的功能开关，或者把一组枚举文案统一格式化。边界是对象没有数组那种天然顺序语义，展示列表最好先转数组再明确排序，不要依赖对象属性遍历顺序。

追问

Lodash 的 map 和原生 Array.map 有什么区别？

原生 Array.map 只处理数组，Lodash 的 _.map 可以处理数组和对象，对对象会把每个 value 映射成数组结果。Lodash 还支持 'name'、['active', true] 这类 shorthand，写列表字段提取时很省事。取舍上，团队如果主要写现代前端，简单数组转换用原生更直观；如果数据来源不稳定，Lodash 的容错和统一写法会更舒服。踩坑是 _.map({a:1,b:2}) 返回数组，不会保留原对象 key，需要保留 key 时用 _.mapValues。

filter、find、some 应该怎么选？

要全部匹配结果用 filter，只要第一个结果用 find，只判断有没有用 some。这三个方法看起来都能写条件，但返回值完全不同，选错后常见问题是把数组当对象用，或者为了判断存在性遍历完整个列表。边界上，find 找不到会返回 undefined，后面访问属性前要配合可选链或默认值。性能上 find 和 some 命中后会停止，比 filter(...).length > 0 更合适。

groupBy 和 keyBy 都能按字段整理数据，差别在哪里？

groupBy 的结果是 { key: array }，因为同一个 key 下可能有多条数据；keyBy 的结果是 { key: object }，同 key 后出现的数据会覆盖前面的。做状态分组、分类展示时用 groupBy，做 id 到对象的索引表时用 keyBy。踩坑点是接口数据 id 如果重复，keyBy 不会报警，最后只留下最后一条。关键数据去重前，最好先用 countBy('id') 找出重复项。

链式调用会不会让代码变慢？

多数业务列表里，链式调用带来的性能差异不明显，可读性收益更重要。真正要注意的是大数组、多次排序、复杂深层路径访问，这些会把浏览器主线程拖慢。边界做法是先控制数据规模，再减少不必要的中间转换，最后才考虑把 Lodash 换成手写循环。不要为了“少一行代码”把所有处理塞进一条链，调试和埋点都会变麻烦。

Lodash 集合方法有什么常见踩坑？

第一个坑是 shorthand 太隐晦，新人看到 _.filter(users, 'active') 可能不知道它等价于判断 truthy。第二个坑是对象遍历顺序不要承载业务含义，尤其是数字字符串 key 会有排序规则差异。第三个坑是把空值当空集合处理，_.isEmpty(null) 返回 true，这在表单校验里可能误判。更稳妥的做法是先明确数据类型，再选择集合方法，而不是拿 Lodash 当万能兜底。