Lodash 函数式工具怎么用，flow、curry、memoize 适合哪些场景？

Lodash 的函数式工具不是为了把 JavaScript 写得更“炫”，而是把一些重复的函数处理模式变成稳定工具。_.flow 适合把多步转换串成管道，_.curry 和 _.partial 适合提前固定部分参数，_.memoize 适合缓存纯函数结果，_.once、_.before、_.after 适合控制函数执行次数。它们好用的前提是函数本身边界清楚、副作用少；如果业务逻辑到处改外部状态，强行套函数式写法只会更难调试。

用这些工具前，可以先问一个问题：这段逻辑有没有稳定的输入输出。如果一个函数依赖全局变量、当前时间、DOM 状态或外部请求，组合起来以后排查成本会明显上升。函数式工具最舒服的场景，是把数组数据从一种形状变成另一种形状，或者把通用函数预配置成业务函数。它们不是架构银弹，只是帮你少写一些重复胶水代码。

常用函数式工具怎么用

_.flow 从左到右执行函数，适合数据清洗、格式化、排序这类步骤明确的流程；_.flowRight 方向相反，更接近数学里的 compose。_.curry 会把多参数函数拆成连续调用，适合生成可复用的小函数；_.partial 更直接，就是预填某几个参数。_.memoize 会按参数缓存结果，适合代价高且结果稳定的计算。_.ary、_.unary 能限制传入参数个数，常用于避免回调拿到多余参数后误用。

js
import _ from 'lodash';

const normalize = _.flow(
  users => users.filter(user => user.active),
  users => _.sortBy(users, 'score'),
  users => users.map(user => ({
    id: user.id,
    name: _.upperFirst(user.name),
    score: _.round(user.score, 1)
  }))
);

const buildUrl = _.curry((host, version, path) => `${host}/api/${version}/${path}`);
const v1Url = buildUrl('https://example.com')('v1');

console.log(v1Url('users'));

追问

_.flow 和直接连续调用有什么区别？

连续调用更直观，尤其是只有两三步时，没有必要为了形式感引入 flow。_.flow 的优势在于把流程变成一个可命名、可复用、可测试的函数，适合多个地方共享同一套数据转换。取舍点是步骤数量和复用价值：一次性逻辑直接写，多处复用再抽成 flow。踩坑点是 flow 中某一步返回结构变了，下一步可能默默拿到错误数据，所以每个阶段的输入输出要稳定。

_.curry 和 _.partial 应该怎么选？

_.partial 更像“先填几个参数”，使用成本低，适合固定日志前缀、接口域名、默认配置。_.curry 更强调把多参数函数拆成逐步传参，适合构造一系列专业化函数。实际项目里，如果团队不熟函数式编程，partial 的可读性通常更好。curry 的坑是参数顺序一旦设计不好，调用会很别扭，所以要把最稳定、最通用的参数放前面。

_.memoize 适合缓存接口请求结果吗？

默认不太适合。memoize 更适合纯计算函数，比如规则解析、树结构查找、昂贵格式化；接口请求有过期、失败重试、权限变化等问题，缓存策略复杂得多。它默认只用第一个参数做缓存 key，多参数函数如果不传 resolver，很容易命中错误缓存。要缓存请求结果，通常需要带 TTL、错误处理和主动失效机制，而不是只包一层 memoize。

_.once 常见用途是什么？

它适合只允许执行一次的初始化逻辑，比如注册全局监听、初始化 SDK、创建单例资源。好处是调用方不用关心是否已经初始化，重复调用也不会造成重复副作用。边界是，一旦第一次调用失败，后续是否还能重试要特别确认；有些实现会把失败也当作“已经执行过”。如果初始化可能失败，最好自己写带状态的重试逻辑，而不是简单依赖 once。

函数式工具会不会让代码变难读？

会，尤其是在团队没有共同习惯时。函数式工具的价值是减少重复和明确数据流，不是把所有逻辑都写成一串嵌套调用。判断是否值得使用，可以看新同事能不能在一分钟内说清每一步做什么。为了炫技而使用 flowRight(curry(partial(...)))，通常只会增加维护成本。

调试时也要留一手。长管道最好给关键步骤起名字，而不是全部写成匿名箭头函数。这样报错堆栈、单元测试和代码评审都会轻松很多。函数式写法的可维护性不来自链条有多长，而来自每个环节都能单独解释、单独验证。

还有一个团队协作上的边界：公共工具函数可以稍微抽象，业务代码不要过度抽象。比如价格格式化、权限过滤、用户排序这些规则稳定，抽成函数很划算；临时活动页的一段转换逻辑，直接写清楚反而更省事。函数式工具一旦让业务同学读不懂，就已经偏离了它提升可维护性的初衷。

小结

Lodash 函数式工具适合把稳定、可组合、少副作用的逻辑抽出来复用。flow 管流程，partial 和 curry 管参数复用，memoize 管纯计算缓存，once 管执行次数。真正的边界不在 API 本身，而在业务逻辑是否足够干净；逻辑越混乱，越应该先拆清楚，再考虑这些工具。