17370845950

柯里化是函数改造模式，将多参函数转为单参链式调用，依赖闭包记忆参数，需权衡可读性与复用性；手写需处理参数累积、长度判断与this绑定，不支持箭头函数或默认参数；适用参数复用与配置化场景，非炫技工具。

JavaScript 中的柯里化不是语法特性，而是一种**函数改造模式**：把一个接受多个参数的函数 fn(a, b, c)，变成每次只收一个参数、返回新函数的形式，最终调用链是 fn(a)(b)(c)。它本质靠闭包“记住”已传参数，直到凑齐才真正执行。 这背后没有魔法，但有明确的取舍——用可读性换灵活性，用嵌套调用换复用能力。下面直说怎么用、为什么用、哪里容易翻车。

怎么手写一个通用 curry 函数？

最简可行版要解决三件事：记参数、判够不够、执行或继续返回函数。关键点是用 fn.length 获取期望参数个数（注意：箭头函数或带默认值的函数会失效），再递归拼参数。

function curry(fn) {
  const 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));
    };
  };
}

• curry 返回的函数必须能正确绑定 this（所以用了 apply）
• 不支持 Rest 参数（...rest）或默认参数的函数，fn.length 会返回 0 或不准确，得手动传入期望参数个数
• 如果原函数有重载逻辑（比如根据参数类型分支），柯里化后可能丢失语义，慎用于复杂工具函数

什么时候真该用柯里化，而不是写个普通封装？

柯里化不是为了炫技，而是解决具体问题。典型场景就两类：

• 参数复用固定值：比如所有 API 请求都走同一个 base URL，fetchUser = curry(fetch)(baseUrl)，后续只传 userId 即可
• 构建配置化函数：日志函数 log(level, tag, msg) → const errorLog = log('error')('auth')，之后每次只填 msg，避免重复写 level 和 tag

反例：简单计算如 add(a, b) 柯里化成 add(a)(b)，除了增加括号没实际收益；反而让调试时堆栈更长、IDE 类型推导变弱。

和偏函数应用（partial）有什么区别？容易混淆吗？

区别很实在：curry 是“严格单参、自动分步”，partial 是“一次预设任意个、剩余全交给你”。比如 _.partial(add, 5) 直接返回 (b) => add(5, b)，一步到位；而 curry(add)(5) 返回的是 (b) => add(5, b)，看起来一样，但机制不同——前者不关心后续参数个数，后者依赖 length 判定是否结束。

• 柯里化函数调用 f(1)(2)(3) 是确定性的；但 f(1, 2)(3) 能否成立，取决于你写的 curry 是否支持“多参合并”（像 Ramda 的 R.curry 就支持，但原生不支持）
• 很多库（如 Lodash）的 _.curry 实际是“柯里化 + 偏应用混合体”，行为比纯数学定义宽松，别当成标准

性能和可维护性上，哪些坑新手常踩？

柯里化本身开销极小，但滥用会带来隐性成本：

• 每次调用都新建函数对象，高频场景（如渲染循环、事件回调）可能触发 GC 压力
• 错误堆栈变深，Chrome DevTools 里看到的调用链是 curried → curried → curried → original，定位原始出错行号更费劲
• TypeScript 类型推导对深度柯里化支持有限，curry(fn) 后的类型往往退化为 any 或需要手动泛型补全

最常被忽略的一点：柯里化不能替代接口设计。如果一个函数本该接收一个配置对象（{ timeout: 3000, retry: 2 }），强行柯里化成 fn(3000)(2)，反而破坏语义清晰度——参数含义没了名字，后期加字段也难扩展。