什么是javascript柯里化_如何编写可复用的柯里化函数【教程】

柯里化是将多参数函数转化为单参数函数链的技术,核心在于固定左侧参数与延迟求值,需显式指定arity以应对默认参数和箭头函数等场景。

柯里化不是语法糖,也不是炫技手段;它本质是把多参数函数拆成一系列单参数函数的调用链。你不需要“学会柯里化”,而是需要判断:当前场景是否真要靠参数分批传入来解耦逻辑、复用配置或适配 API 签名。

什么是 curry?它和普通闭包有什么区别?

柯里化函数的关键特征是「固定左侧参数 + 延迟求值」。它和随手写的闭包不同:闭包可能只封住 1 个变量,而柯里化必须能处理任意长度的参数列表,并在参数数量满足原函数要求时自动执行。

常见误解是把 function(a) { return function(b) { return a + b; } } 当作通用柯里化 —— 这只是针对二元函数的手写特例,不可复用。

  • 真正可复用的 curry 必须能接受任意函数(如 Math.max_.reduce、自定义三参数函数)
  • 它不修改原函数,只返回新函数,且新函数支持「一次传多个」或「分多次传」
  • 不能依赖 length 精确判断(箭头函数、有默认参数的函数会失准),需提供显式 arity 参数或约定行为

如何手写一个健壮的 curry 函数?

最简可用版本应支持:参数累积、自动触发、兼容 rest 参数。不要试图一步到位支持所有边界(如 new 调用、this 绑定),先保证核心路径可靠。

以下是一个生产环境够用的实现(不依赖外部库,兼容 ES5+):

function curry(fn, arity = fn.length) {
  return function curried(...args) {
    if (args.length >= arity) {
      return fn.apply(this, args);
    }
    return function(...moreArgs) {
      return curried.apply(this, args.concat(moreArgs));
    };
  };
}
  • arity 显式传入更可靠:比如 curry((a, b, c = 1) => a + b + c, 3),避免因默认参数导致 fn.length === 2 的误判
  • 使用 apply 保留 this 上下文,否则类方法柯里化后丢失实例绑定
  • 不使用 bind 链式构造,避免创建大量中间函数对象,影响性能

curry 在真实项目中该怎么用?别硬套

柯里化不是为了“看起来函数式”,而是解决具体问题。下面这些才是典型适用场景:

  • 配置复用:const getProp = curry((prop, obj) => obj[prop]); const getName = getProp('name'); getName({name: 'Alice'})
  • API 适配:const fetchWithToken = curry((token, url

    , options) => fetch(url, {...options, headers: {'Authorization': token}}));
  • map/filter 配合:[1,2,3].map(curry(Math.pow)(2)) // [1,4,9](注意:此处 Math.pow 是二元函数,curry(Math.pow)(2) 返回的是以 2 为底的幂函数)

容易踩的坑:

  • 对异步函数柯里化后,忘记返回 Promise,导致调用链中断
  • 把柯里化当缓存用(比如以为 curry(fn)(a)(b)fn(a,b) 更快)—— 实际上多了一层函数调用开销
  • 在循环中无节制地柯里化,造成内存泄漏(闭包长期持有外部变量)

为什么你不该直接用 Lodash 的 _.curry

_.curry 默认按 fn.length 推断参数个数,遇到带默认值的函数((a, b = 1, c) => {})、箭头函数(=>)、或经过 Babel 编译的代码时,length 常为 0 或不准确,导致提前执行或永远不执行。

如果你已在用 Lodash,更稳妥的做法是:

  • 显式传 arity_.curry(fn, 3)
  • 改用 _.partial(固定左侧参数,不延迟)替代部分场景,语义更明确
  • 对关键路径函数,宁可手写专用柯里化器,也不依赖自动推断

柯里化的复杂点不在写法,而在判断「什么时候不该用」—— 参数是否真的需要分批注入?调用方是否清楚这个链式结构?调试时堆栈是否还能快速定位?这些问题比实现本身更重要。