Currying是将多参数函数转换为一系列单参数函数的过程，核心逻辑是“收集参数→够则执行，不够则返回新函数”，需注意this绑定、参数副本及与partial application的区别。
Currying 是把一个接收多个参数的函数，转换成一系列只接收一个参数的函数的过程。它不是语法糖，而是函数式编程里一种明确的变换策略——每次调用返回新函数，直到参数收齐才真正执行。
curry 函数怎么手动实现
核心逻辑是「收集参数 → 参数够了就执行，不够就返回新函数」。常见错误是直接 arguments 或闭包变量没处理好，导致多次调用共享同一份参数数组。
正确做法是每次调用都生成独立的参数副本：
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));
};
}
};
}
注意点：
立即学习“Java免费学习笔记（深入）”；
-
fn.length返回函数定义时的形参个数，不是实际调用时传入的个数 - 必须用
apply或call保证this上下文正确（尤其在对象方法上使用时） - 箭头函数不能用作
curried的主体，因为它没有自己的this和arguments
和 partial application 的区别在哪
很多人混淆 currying 和 partial application。关键区别：currying 总是返回单参数函数链，且数量固定；partial 可一次填多个，也不强制“逐个”调用。
比如：
-
curry(add)(1)(2)(3)—— 必须三个单参数调用 -
partial(add, 1, 2)(3)或partial(add, 1)(2, 3)—— 都合法
JavaScript 原生没有 curry，但有 bind，它更接近 partial： add.bind(null, 1) 固定第一个参数，但不强制后续只能一个一个传。
真实项目里哪些地方会用到
currying 不是炫技，它在以下场景有明确价值：
- 配置复用：比如封装
fetch请求时，先curry(apiCall)(baseUrl)(timeout)，后续不同接口只需补路径和 body - 事件处理器预置：
onClick={curry(handleClick)('user-delete')(userId)}，避免内联函数导致子组件无谓重渲染 - 组合函数：配合
compose或pipe使用，如pipe(map(curry(add)(1)), filter(isEven)) - 日志/埋点装饰：
curry(logWithPrefix)('API')('GET /users')比拼字符串更可控
性能上要注意：每层 currying 都新增函数对象，高频调用路径（如 React render 中）慎用深度 curry；更推荐在初始化或模块顶层做一次 curry，而不是每次渲染都调用。
为什么现代框架里少见显式 curry
React 的 useCallback、Vue 的 computed、甚至 Lodash 的 _.curry 默认是“惰性求值 + 缓存”，但开发者往往更倾向用闭包或工厂函数替代，因为更直观。比如：
const createHandler = (type, id) => () => dispatch({ type, payload: id });
// 比 curry(handleAction)(type)(id)() 更易读，也更容易加类型注解
真正需要 curry 的，是那些要被通用工具函数（如 R.map、fp-ts 的 pipe）消费的函数。否则，过度 curry 反而增加调用栈深度和调试成本。
