柯里化是将多参数函数转为单参数函数链，每次只传一个参数直至收齐；部分应用则固定若干参数，新函数可一次接收多个剩余参数。
什么是柯里化，和部分应用有什么区别
柯里化（currying）是把一个接收多个参数的函数，转换成一系列只接收一个参数的函数链；而部分应用（partial application）是固定住原函数的若干个参数，返回一个新函数，它仍可接收剩余参数（数量不固定，也不强制单参数）。两者常被混淆，但关键差异在 curry 要求每次只传一个参数、必须“逐步收齐”，partial 则允许一次传多个已知参数。
手写一个通用的 curry 函数（支持任意参数个数）
核心思路是：返回的函数不断收集参数，直到参数总数 ≥ 原函数的期望参数个数（fn.length），才真正执行。注意：fn.length 只反映形参个数，不处理 rest 参数（...args），所以适用于传统函数声明或带明确形参的箭头函数。
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));
};
}
};
}
- 调用
curry(add)(1)(2)(3)会返回6；curry(add)(1, 2)(3)也合法（因为第二步就凑够了 3 个参数） - 不能靠
arguments检查——ES6+ 箭头函数无arguments，统一用 rest 参数更可靠 -
fn.length对(a, b, c = 1)返回3，即使c有默认值；对(...args)返回0，此时该curry不适用
实现 partial（更贴近实际使用场景）
比 curry 更灵活、更常用：你不需要等“参数个数达标”，只要先填上几个确定的值就行。ES6 已内置 Function.prototype.bind，但它硬绑定 this，且不支持占位符；手动实现可支持 _ 占位（类似 Lodash 的 partial）。
const _ = Symbol('placeholder');
function partial(fn, ...presetArgs) {
return function (...laterArgs) {
let args = [];
let presetIndex = 0;
let laterIndex = 0;
for (let i = 0; i < fn.length; i++) {
if (presetIndex < presetArgs.length && presetArgs[presetIndex] === _) {
args.push(laterArgs[laterIndex++]);
presetIndex++;
} else if (presetIndex < presetArgs.length) {
args.push(presetArgs[presetIndex++]);
} else {
args.push(laterArgs[laterIndex++]);
}
}
return fn.apply(this, args);
};
}
-
partial(Math.pow, _, 2)(3)→9；partial(console.log, '[DEBUG]', _)→ 后续只传消息内容即可 - 占位符
_用Symbol避免和真实参数值冲突（比如不会误把字符串"_"当占位符） - 不依赖
fn.length做最终调用判断，而是严格按形参个数填充，避免多余参数被忽略
为什么不要直接用 bind 实现 curry
Function.prototype.bind 是部分应用工具，不是柯里化工具。它返回的函数仍接受任意多参数（包括多余参数），且无法“暂停”在中间状态。例如：
立即学习“Java免费学习笔记（深入）”；
function add(a, b, c) { return a + b + c; }
const add5 = add.bind(null, 5); // partial，不是 curry
add5(2, 3); // ✅ 10
add5(2)(3); // ❌ TypeError: add5(...) is not a function
-
bind固定的是前缀参数，但不改变调用签名；返回函数仍是一次性接收剩余所有参数 - 若强行用
bind嵌套模拟 curry（如add.bind(null, 1).bind(null, 2)），会丢失原始this绑定上下文，且无法动态决定何时执行 - 现代开发中，真需要柯里化时，优先选明确语义的
curry实现；日常参数预设，partial或直接箭头函数（x => f(1, x)）更轻量
柯里化本身不是银弹，过度使用会让调用链变长、调试困难；真正需要它的场景其实有限——比如函数式组合（compose）、配置驱动的策略函数、或与 Ramda / Sanctuary 等库协同工作。多数时候，一个清晰的 partial 或具名中间函数，反而更易维护。
