Lodash 在实际项目中怎么用？哪些场景比原生 JS 更合适？

Lodash 在项目里的价值，通常不是“多一个工具库”，而是把容易写错的细碎数据处理变成稳定表达。比如接口字段大小写混乱、表单要清洗空值、列表要按条件分组、用户输入要防抖，这些都不是算法难题，却很容易在业务代码里散成一堆临时函数。合理使用 Lodash 的关键是划清边界：高频、通用、容易出错的处理交给它；简单、直白、团队都熟的逻辑留给原生 JS。

场景一：接口数据清洗

真实接口很少像文档一样干净。后端可能返回 snake_case 字段，空字符串、null、缺失字段混在一起，前端还要把这些数据喂给组件。Lodash 的 get、pick、omitBy、mapKeys 很适合做入口层清洗，把脏数据挡在视图层之外。

javascript
import _ from 'lodash';

function normalizeUser(raw) {
  return {
    id: _.get(raw, 'id'),
    name: _.trim(_.get(raw, 'profile.name', '')),
    email: _.toLower(_.get(raw, 'email', '')),
    tags: _.compact(_.split(_.get(raw, 'tags', ''), ','))
  };
}

const users = _.map(apiResponse.data, normalizeUser);

这里的取舍是，清洗逻辑最好集中在 API adapter 或 service 层，不要散落在组件里。否则同一个字段在 A 页面 trim 了，在 B 页面没 trim，问题会变得很隐蔽。边界上，_.get 的默认值只在路径结果是 undefined 时生效，结果是 null 时不会替换，必要时还要配合 ??。

场景二：表单处理和参数构造

表单提交前经常要做三件事：去掉首尾空格、删掉空字段、把字段名转成后端需要的格式。mapValues、omitBy、pickBy 能让这类逻辑比较集中。注意不要一刀切删除所有 falsy 值，0、false 在筛选条件里可能是合法输入。

javascript
function buildQuery(form) {
  return _.chain(form)
    .mapValues(v => typeof v === 'string' ? _.trim(v) : v)
    .omitBy(v => v === '' || v == null)
    .mapKeys((_, key) => _.snakeCase(key))
    .value();
}

这个场景最常见的坑是误用 _.isEmpty。它对空数组、空对象返回 true 没问题，但对 false、0 也容易让人误会，校验规则必须按字段类型写清楚。实际项目里，我更建议把“空”的定义写成业务函数，比如 isBlankQueryValue，别把 Lodash 的通用判断直接当业务判断。

场景三：列表分组、排序和统计

后台管理系统、报表页、看板页很常见这种需求：按状态分组、按金额排序、算总数或总额。Lodash 的 groupBy、orderBy、sumBy、countBy 能把数据处理写成短管道。相比手写 reduce，它更少样板代码，也更容易被后来的人读懂。

javascript
const summary = _.chain(orders)
  .groupBy('status')
  .mapValues(list => ({
    count: list.length,
    amount: _.sumBy(list, 'amount')
  }))
  .value();

场景四：用户交互限频

搜索框、窗口 resize、滚动加载这些交互很容易在短时间触发几十次。_.debounce 和 _.throttle 能把频率压下来，让请求、计算和渲染都更可控。实际使用时要把函数实例保存下来，不能每次渲染都重新创建，否则取消和复用都会失效。这个场景的边界是用户关键操作不能只靠前端限频保护，例如提交订单仍然要依赖后端幂等和状态校验。

追问

项目里什么时候不该引入 Lodash？

如果只用到一两个原生已经很好写的方法，比如 arr.map、arr.includes，没必要为了它增加依赖。现代浏览器和 Node 已经补齐了很多基础能力，简单逻辑用原生更利于新人理解。取舍点在于团队已有依赖、打包体积、代码一致性，而不是“Lodash 老不老”。如果确实要用，尽量按需引入或确认构建工具能 tree-shaking。

Lodash 在 React 或 Vue 里最常用在哪里？

最常见是输入防抖、列表派生数据、表单参数整理和安全读取深层字段。比如搜索框输入时用 debounce 控制请求频率，能减少服务端压力，也能避免响应乱序造成闪烁。边界是组件卸载时要取消防抖函数，否则可能出现卸载后还 setState 的警告。Vue 和 React 都一样，工具函数别直接绑死组件生命周期，最好在 effect 或 unmounted 里清理。

debounce 和 throttle 在业务上怎么选？

debounce 适合“停下来再执行”，例如搜索联想、窗口尺寸变化后的布局计算。throttle 适合“持续触发但固定频率执行”，例如滚动监听、拖拽位置上报。踩坑点是两者都有 leading、trailing 选项，默认行为不理解时，第一次触发或最后一次触发可能和预期不同。涉及保存、支付、提交按钮这类动作时，除了防抖还要做服务端幂等，前端限制不能当唯一防线。

用 Lodash 处理接口数据会不会掩盖后端问题？

会，所以数据清洗要有边界。前端可以对缺失字段给默认值、对展示字段做格式化，但不能悄悄吞掉关键业务错误，比如订单金额缺失、权限字段异常。更好的做法是在 adapter 层记录异常或上报埋点，让问题能被发现。Lodash 能让代码更稳，但不应该把错误数据包装成“看起来正常”。

团队怎么避免 Lodash 用法不统一？

可以约定几条简单规则：数组基础转换优先原生，深层路径和对象集合处理允许 Lodash，复杂链式调用必须拆命名函数。代码评审时重点看数据语义是否清楚，而不是追求所有地方写法一致。边界上，不要在同一个文件里同时出现 lodash 全量引入和 lodash/debounce 按需引入。踩坑最多的不是方法本身，而是团队没有明确哪些场景该用、哪些场景不该用。