17370845950

柯里化是通过闭包实现的参数分批接收模式，返回新函数而非修改原函数；核心是动态累积参数至指定元数（arity）后执行，需显式传入arity以应对默认值或rest参数导致的length失效。

JavaScript 中的函数柯里化不是语法特性，而是靠闭包和参数控制实现的模式；它本身不改变原函数，而是返回一个能「分批接收参数」的新函数。

什么是 curry？关键看参数收口逻辑

柯里化函数的核心行为是：把接受多个参数的函数，转成每次只接收一个（或固定数量）参数的函数链，直到参数总数满足才执行原逻辑。它不是简单地用 bind 预设参数，而是动态判断剩余参数数。

• curry 的返回值必须是函数，且该函数要能持续“记住”已传入的参数
• 不能依赖函数的 length 属性做绝对判断——箭头函数、带默认值、rest 参数都会让 fn.length 失效
• 更稳妥的方式是显式传入期望的参数个数（arity），或由用户在调用时主动触发执行（如末尾传 undefined 或调用 ()）

手写一个基础版 curry 函数（支持固定元数）

以下实现假设你明确知道原函数需要几个参数（即 arity），这是最常见也最可控的场景：

function curry(fn, arity = fn.length) {
  return function curried(...args) {
    if (args.length >= arity) {
      return fn.apply(this, args);
    } else {
      return function(...moreArgs) {
        return curried.apply(this, args.concat(moreArgs));
      };
    }
  };
}

使用示例：

const add = (a, b, c) => a + b + c;
const curriedAdd = curry(add, 3);
console.log(curriedAdd(1)(2)(3)); // 6
console.log(curriedAdd(1, 2)(3)); // 6
console.log(curriedAdd(1)(2, 3)); // 6

• 这里 arity = fn.length 是默认回退，但仅适用于无默认值、无 rest 参数的普通函数
• 每次调用 curried 都会累积参数，直到达到 arity 才真正调用 fn
• 注意 this 绑定：用 apply 保证上下文正确，否则在对象方法上柯里化会丢失 this

遇到箭头函数或带默认值的函数怎么办？

这类函数的 fn.length 不可靠（例如 (a = 1, b) => {} 的 length 是 0），强行依赖会导致提前执行或死循环。此时必须显式传入 arity：

const flexibleFn = (x = 'default', y, z) => `${x}-${y}-${z}`;
// ❌ 错误：curry(flexibleFn) 会因 length === 0 立即执行
// ✅ 正确：curry(flexibleFn, 3)

• 不要试图自动推导“真实必填参数个数”，JS 没有运行时反射支持这个
• 如果

  

  封装为工具库，建议强制要求传 arity，或提供 curryN(fn, n) 明确命名来规避歧义
• 某些场景下用 placeholder（如 Lodash 的 _）配合部分应用（partial application）比纯柯里化更实用

为什么不用 Function.prototype.bind 直接替代？

bind 能预设参数，但它返回的函数仍接受**剩余全部参数一次性传入**，不支持“一次一个”的链式调用：

const add = (a, b, c) => a + b + c;
const bound = add.bind(null, 1);
bound(2, 3); // ✅ 可行，但 bound(2)(3) 会报错：not a function

• bind 是部分应用（partial application），不是柯里化（currying）
• 柯里化强调「每次只吃一个」的严格分步，而 bind 是「先吞几个，剩下一口吃完」
• 性能上，柯里化多一层闭包嵌套和数组拼接，高频调用场景需权衡；若只需预设前几个参数，bind 更轻量

真正难的不是写一个能跑的 curry，而是想清楚：你要的是参数分步的语义表达，还是仅仅为了复用预设值。后者用 bind 或高阶工厂函数更直接；前者才需要认真处理参数累积、this、arity 和边界调用逻辑。