柯里化是参数分步求值的转换策略，非函数组合本身，但使多参函数适配 compose 链所需的单参数要求；需基于 fn.length 判断参数个数，注意 this 绑定、箭头函数无 length、rest 参数限制及真实场景中的 this 和异步语义问题。

柯里化不是函数组合，但能支撑组合的灵活性

柯里化（curry）本身不等于函数组合（compose），它是一种参数分步求值的转换策略。只有当函数被柯里化后，才更容易嵌入到 compose 或 pipe 链中——因为单参数函数是组合链的基本单元。

怎么手写一个安全的 curry 函数？

常见错误是直接递归调用自身却忽略 this 绑定、或没处理形参长度动态变化（比如箭头函数无 length）。标准实现应基于目标函数的 length 属性判断需收集几个参数，且每次调用都返回新函数。

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

• fn.length 只反映**显式声明的形参个数**，不含 rest 参数（...rest）
• 箭头函数没有 arguments 和 length，传入箭头函数会退化为只收 0 个参数就执行
• 若需支持 rest 参数，得改用 Function.prototype.toString() 解析源码——但不推荐，破坏可维护性

为什么 curry 后才能和 compose 自然配合？

组合函数如 compose(f, g) 的定义是 x => f(g(x))，它要求每个函数都只接收一个参数。如果原始函数是 add(a, b, c)，你没法直接写 compose(double, add)；但柯里化后得到 add(1)(2)(3)，就能提取中间态：比如 add(1)(2) 是一个等待第三个参数的单参函数，可参与组合。

• compose 链中每个环节必须是 (x) => y 形式，多参函数必须先被柯里化或部分应用
• 不要混淆 curry 和 partial：前者是“按形参个数自动分步”，后者是“固定前 N 个参数”，partial 不保证返回单参函数
• Lodash 的 _.curry 默认是“占位符敏感”的，而原生手写版没有占位逻辑，遇到 curry(fn)(1, _, 3) 会直接报错

真实项目中容易被忽略的边界点

柯里化在异步流程、React 事件处理器、或 Class 方法绑定场景下容易出问题——不是语法错，而是语义错。

• 类方法柯里化后丢失 this：必须用 curry(fn.bind(this)) 或在 class 字段中定义箭头函数
• Promise 链中误把 curry(fetch) 当作可组合单元：fetch 返回 Promise，组合链需要的是 (url) => Promise，而 curry(fetch) 是 (input, init) => Promise，仍需进一步固定 init
• TypeScript 中，手写 curry 很难完整推导泛型类型，建议用 ts-toolbelt 或 fp-ts 的 curry 实现