柯里化是函数改造模式，将多参函数转为单参链式调用，依赖闭包记忆参数，需权衡可读性与复用性；手写需处理参数累积、长度判断与this绑定，不支持箭头函数或默认参数；适用参数复用与配置化场景，非炫技工具。
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 判定是否结束。
立即学习“Java免费学习笔记（深入）”；
- 柯里化函数调用
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)，反而破坏语义清晰度——参数含义没了名字，后期加字段也难扩展。
