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 反而增加调用栈深度和调试成本。