柯里化是将多参函数转换为单参函数链的技术，核心在于分步传参而非一次性传递；它改变调用节奏但不改变逻辑，需手动实现或使用Lodash等库以应对占位符、rest参数等复杂场景。
柯里化函数不是语法糖，而是把接受多个参数的函数变换成接受单一参数（第一个参数）并返回接收余下参数的新函数的技术。它不改变原函数逻辑，只改变调用方式。
什么是 curry？它和普通函数调用有什么本质区别？
核心区别在于参数传递节奏：普通函数必须一次性给全所有参数；柯里化函数允许分多次、逐步传入，每次只传一个（或固定数量），中间返回的是函数，直到参数“凑够”才真正执行。
比如 add(1, 2, 3) 是一次调用；而柯里化后的 add(1)(2)(3) 是三次调用，且 add(1) 返回函数，add(1)(2) 还返回函数，只有最后一步才返回结果。
注意：JavaScript 没有原生 curry 方法，必须手动实现或借助库（如 Lodash 的 _.curry）。
立即学习“Java免费学习笔记（深入）”；
如何手写一个通用的 curry 函数？
关键思路是：捕获原始函数的期望参数个数（fn.length），用闭包累积参数，达到数量后执行；未达数量则返回新函数继续接收。
- 不能依赖
arguments在箭头函数中——所以内部要用普通函数 -
fn.length只反映形参个数，对含默认值或 rest 参数的函数可能不准 - 要支持提前传入部分参数，比如
curry(add)(1, 2)(3)或curry(add)(1)(2, 3)，需递归处理“参数溢出”
function curry(fn) {
return function curried(...args) {
if (args.length >= fn.length) {
return fn.apply(this, args);
} else {
return function(...moreArgs) {
return curried.apply(this, args.concat(moreArgs));
};
}
};
}
什么时候该用柯里化？哪些场景容易误用？
适合场景：
- 预设配置：如
const logError = curry(console.log)('ERROR:')，后续只需传具体消息 - 函数式组合：配合
map、filter时避免写匿名函数，例如[1,2,3].map(curry(Math.pow)(2))等价于平方映射 - API 封装：把带 token、baseURL 的请求函数柯里化，分离环境配置与业务参数
容易踩坑的地方：
- 性能开销：每次调用都新建函数，高频场景慎用
- 无法正确处理
this绑定（上面实现中用了apply(this, ...)是为兼容，但若原函数依赖严格this上下文，仍需额外bind） - 和 TypeScript 类型推导不友好，泛型参数容易丢失，需手动声明类型
为什么 lodash.curry 比手写更可靠？
它解决了几个手写常忽略的问题：
- 支持占位符（
_），允许跳过中间参数：curry(add)(1, _, 3)(2)→6 - 自动识别 rest 参数（
...args），不依赖fn.length - 提供
curryRight和uncurry等配套能力 - 对嵌套柯里化、重入等边界情况做了防御
实际项目中，除非明确需要极简实现或教学演示，否则直接用 _.curry 更省心。
