17370845950

柯里化是将多参数函数转化为单参数函数链的技术，核心在于固定左侧参数与延迟求值，需显式指定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（固定左侧参数，不延迟）替代部分场景，语义更明确
• 对关键路径函数，宁可手写专用柯里化器，也不依赖自动推断

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