柯里化是将多参数函数转化为单参数函数链的技术，核心在于固定左侧参数与延迟求值，需显式指定arity以应对默认参数和箭头函数等场景。
柯里化不是语法糖，也不是炫技手段；它本质是把多参数函数拆成一系列单参数函数的调用链。你不需要“学会柯里化”，而是需要判断：当前场景是否真要靠参数分批传入来解耦逻辑、复用配置或适配 API 签名。
什么是 curry？它和普通闭包有什么区别？
柯里化函数的关键特征是「固定左侧参数 + 延迟求值」。它和随手写的闭包不同：闭包可能只封住 1 个变量，而柯里化必须能处理任意长度的参数列表，并在参数数量满足原函数要求时自动执行。
常见误解是把 function(a) { return function(b) { return a + b; } } 当作通用柯里化 —— 这只是针对二元函数的手写特例，不可复用。
- 真正可复用的
curry必须能接受任意函数（如Math.max、_.reduce、自定义三参数函数） - 它不修改原函数，只返回新函数，且新函数支持「一次传多个」或「分多次传」
- 不能依赖
length精确判断（箭头函数、有默认参数的函数会失准），需提供显式arity参数或约定行为
如何手写一个健壮的 curry 函数？
最简可用版本应支持：参数累积、自动触发、兼容 rest 参数。不要试图一步到位支持所有边界（如 new 调用、this 绑定），先保证核心路径可靠。
立即学习“Java免费学习笔记（深入）”；
以下是一个生产环境够用的实现（不依赖外部库，兼容 ES5+）：
function curry(fn, 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));
};
};
}
-
arity显式传入更可靠：比如curry((a, b, c = 1) => a + b + c, 3)，避免因默认参数导致fn.length === 2的误判 - 使用
apply保留this上下文，否则类方法柯里化后丢失实例绑定 - 不使用
bind链式构造，避免创建大量中间函数对象，影响性能
curry 在真实项目中该怎么用？别硬套
柯里化不是为了“看起来函数式”，而是解决具体问题。下面这些才是典型适用场景：
- 配置复用：
const getProp = curry((prop, obj) => obj[prop]); const getName = getProp('name'); getName({name: 'Alice'}) - API 适配：
const fetchWithToken = curry((token, url, options) => fetch(url, {...options, headers: {'Authorization': token}})); - 与
map/filter配合：[1,2,3].map(curry(Math.pow)(2)) // [1,4,9]（注意：此处Math.pow是二元函数，curry(Math.pow)(2)返回的是以 2 为底的幂函数）
容易踩的坑：
- 对异步函数柯里化后，忘记返回 Promise，导致调用链中断
- 把柯里化当缓存用（比如以为
curry(fn)(a)(b)比fn(a,b)更快）—— 实际上多了一层函数调用开销 - 在循环中无节制地柯里化，造成内存泄漏（闭包长期持有外部变量）
为什么你不该直接用 Lodash 的 _.curry？
_.curry 默认按 fn.length 推断参数个数，遇到带默认值的函数（(a, b = 1, c) => {}）、箭头函数（=>）、或经过 Babel 编译的代码时，length 常为 0 或不准确，导致提前执行或永远不执行。
如果你已在用 Lodash，更稳妥的做法是：
- 显式传
arity：_.curry(fn, 3) - 改用
_.partial（固定左侧参数，不延迟）替代部分场景，语义更明确 - 对关键路径函数，宁可手写专用柯里化器，也不依赖自动推断
柯里化的复杂点不在写法，而在判断「什么时候不该用」—— 参数是否真的需要分批注入？调用方是否清楚这个链式结构？调试时堆栈是否还能快速定位？这些问题比实现本身更重要。
