柯里化是将多参函数转为单参函数链，核心在于分批注入参数；需动态判断参数数量、正确绑定this、隔离闭包；适用于固定部分参数的高频场景，非万能解法。
柯里化函数不是“把函数变高级”的语法糖，而是把一个接收多个参数的函数，转换成一系列只接收一个参数的函数链。它真正提升复用性的地方，不在于写法多酷，而在于能提前固化部分参数，让后续调用更专注、更灵活。
什么是 curry？它和普通函数调用有什么本质区别？
核心区别在于参数“分批注入”的能力。普通函数必须一次性给齐所有参数才能执行；而柯里化后的函数可以先传一部分，返回新函数，等后续再补全剩余参数。
比如原函数 add(a, b, c)，柯里化后变成 add(1)(2)(3) 或 add(1)(2)(3) 都合法，甚至可以中途暂停：const add5 = add(5)，add5(3)(2) 也成立。
常见错误是以为只要用箭头函数嵌套就是柯里化——其实关键在“自动判断参数是否收齐”，否则只是手动写的多层闭包。
立即学习“Java免费学习笔记（深入）”；
手写一个健壮的 curry 函数要注意什么？
不能硬编码参数个数，得靠 fn.length 获取形参数量，并递归收集实参，直到够数才执行原函数。
- 必须处理
this绑定：用fn.apply(this, args)而非直接fn(...args) - 要支持多次调用同一柯里化函数时各自独立缓存参数（闭包隔离）
-
fn.length对有默认参数或 rest 参数的函数会失真，生产环境建议配合类型系统或显式传入arity
function curry(fn, arity = fn.length) {
return function curried(...args) {
if (args.length >= arity) {
return fn.apply(this, args);
}
return function(...nextArgs) {
return curried.apply(this, args.concat(nextArgs));
};
};
}
实际项目中，哪些场景用 curry 能明显减少重复代码？
不是所有多参函数都值得柯里化。真正省事的，是那些“固定一部分、变化另一部分”的高频组合。
- 事件处理器中固化配置：
const handleClick = curry(handleAction)('submit')，绑定到onClick时不用再写箭头函数 - API 请求封装：
const getUser = curry(api.get)('/users')，后续调用getUser(123)直接拼路径 - 日志函数定制：
const warn = curry(log)('WARN')，比每次写log('WARN', msg)更轻量
注意：如果固化参数后只剩一两个调用点，或者参数顺序经常变动，强行柯里化反而增加理解成本。
为什么 lodash.curry 和手写版行为可能不一致？
因为 lodash.curry 默认采用“宽容模式”：即使参数没凑够，也会尝试执行（若函数能运行）；而标准实现严格等待参数达标。更关键的是，它支持占位符（如 _），允许跳过中间参数：
const abc = (a, b, c) => a + b + c; const curried = _.curry(abc); curried(1, _, 3)(2); // → 6
这种灵活性代价是内部逻辑更重，且与原生 length 判断脱钩。如果你依赖精确参数计数，或需要最小体积，别直接替换成 lodash.curry。
最易被忽略的一点：柯里化函数本身是纯函数，但一旦它闭包里捕获了外部可变状态（比如某个全局计数器），复用性就崩了——这时候你复用的不是逻辑，是副作用。
