柯里化是参数分步求值的转换策略，非函数组合本身，但使多参函数适配 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 方法绑定场景下容易出问题——不是语法错，而是语义错。
立即学习“Java免费学习笔记（深入）”；
- 类方法柯里化后丢失
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实现
