Lodash 数值方法怎么用，哪些场景比原生 Math 更合适？

Lodash 的数值方法主要解决三类问题：简单四则运算、集合里的数值统计，以及带边界的数值生成或校验。它不是要替代所有 Math API，而是在你已经用 Lodash 处理数组、对象、集合时，让数值逻辑也保持同一套写法。比如订单金额汇总、评分均值、折扣边界限制，用 _.sumBy、_.meanBy、_.clamp 会比手写循环更直观。真正要注意的是，Lodash 不会替你解决浮点精度、货币精算和随机数安全问题，这些场景仍然要用专门方案。

真正落地时，还要先分清计算发生在哪一层。如果只是前端展示汇总，Lodash 的写法足够轻；如果结果要入库、参与结算或影响权限，最好把规则放在后端并配合测试用例。另一个容易忽略的点是单位，接口返回元、分、百分比、小数比例时，方法名再清楚也挡不住单位混乱。把单位转换写在计算前面，比在每个表达式里临时修补更稳。

常用数值方法怎么分组

四则运算有 _.add、_.subtract、_.multiply、_.divide，语义很清楚，适合放在组合式数据处理中。取整方法有 _.round、_.ceil、_.floor，都支持 precision，可以处理保留小数位的场景。统计方法更常用，包括 _.sum、_.sumBy、_.mean、_.meanBy、_.maxBy、_.minBy，适合从对象数组里提取字段再计算。范围和边界相关方法包括 _.range、_.random、_.clamp、_.inRange，常见于分页、评分、进度条和表单限制。

js
import _ from 'lodash';

const orders = [
  { id: 1, price: 19.9, count: 2 },
  { id: 2, price: 8.5, count: 5 },
  { id: 3, price: 120, count: 1 }
];

const total = _.sumBy(orders, item => item.price * item.count);
const average = _.round(_.meanBy(orders, 'price'), 2);
const progress = _.clamp(126, 0, 100);
const pages = _.range(1, 6);

console.log({ total, average, progress, pages });

追问

_.sumBy 和 Array.prototype.reduce 应该怎么选？

如果只是对对象数组按字段求和，_.sumBy(list, 'amount') 可读性通常更好，维护者一眼就知道目的。reduce 的优势是灵活，可以同时做过滤、累加、分组等多步逻辑，但写多了容易把业务意图藏在回调里。取舍标准很简单：单一统计用 sumBy，多阶段聚合用 reduce。踩坑点是 sumBy 不会自动清洗脏数据，字段是字符串金额时可能得到拼接或隐式转换问题，最好先把数据归一化。

_.round(number, precision) 能解决 JS 浮点精度问题吗？

它能改善展示层的小数位问题，但不能从根上解决二进制浮点误差。比如金额计算里先出现了 0.1 + 0.2 的误差，再用 round 只是把结果修饰成看起来正确。实际项目里，订单、钱包、发票这类强一致金额应该用整数分存储，或者使用 decimal 类库。Lodash 的取整方法更适合报表展示、评分、百分比，不适合作为财务计算的底层保证。

_.clamp 和手写 Math.min(Math.max()) 有什么区别？

结果上两者很接近，_.clamp(value, min, max) 的优势是语义更直接，读起来就是“把值限制在范围内”。手写 Math.min(Math.max(value, min), max) 没问题，但嵌套表达式在复杂条件里不太好读。边界上要注意参数顺序，Lodash 是先值再上下限，团队里有人从其他语言迁移时容易写反。对于滑块、进度、评分上限这类 UI 逻辑，clamp 往往比手写表达式更不容易出错。

_.random 可以用来生成验证码或抽奖结果吗？

不建议。_.random 底层面向普通业务随机，比如随机展示提示文案、生成演示数据、测试列表取样。验证码、抽奖、令牌这类场景涉及安全或公平性，应该使用 Web Crypto、Node crypto 或后端可信随机源。另一个坑是 floating 参数会影响是否返回浮点数，团队没有约定时容易出现整数和小数混用。简单随机可以用它，安全随机不要用它。

_.maxBy、_.minBy 遇到空数组会怎样？

空数组会返回 undefined，这点在链式读取里很容易引发后续空指针问题。比如你拿最高价商品后直接读 .price，线上遇到空列表就会报错。实际写法最好先给兜底值，或者在业务层明确空状态。maxBy 的价值是让比较字段很清楚，但它不负责业务兜底，边界判断仍然要自己写。

还有一种常见情况是报表字段临时增加，比如从总销售额改成按有效订单求和。这时 sumBy 的回调可以先过滤无效状态，也可以先用 filter 再求和。前者代码短，后者调试时更容易看清中间结果。数据量不大时优先可读性，别为了少遍历一次把规则塞得太满。

小结

Lodash 数值方法适合做“业务数据处理中的小计算”：求和、均值、最大最小、范围限制、分页序列。它让代码更短，也让意图更明显。遇到货币精度、安全随机、大规模数值计算时，不要因为项目里已经引入 Lodash 就顺手全用它，选对工具比写法统一更重要。