17370845950

柯里化是将多参函数转换为单参函数链的技术，核心在于分步传参而非一次性传递；它改变调用节奏但不改变逻辑，需手动实现或使用Lodash等库以应对占位符、rest参数等复杂场景。

柯里化函数不是语法糖，而是把接受多个参数的函数变换成接受单一参数（第一个参数）并返回接收余下参数的新函数的技术。它不改变原函数逻辑，只改变调用方式。

什么是 curry？它和普通函数调用有什么本质区别？

核心区别在于参数传递节奏：普通函数必须一次性给全所有参数；柯里化函数允许分多次、逐步传入，每次只传一个（或固定数量），中间返回的是函数，直到参数“凑够”才真正执行。

比如 add(1, 2, 3) 是一次调用；而柯里化后的 add(1)(2)(3) 是三次调用，且 add(1) 返回函数，add(1)(2) 还返回函数，只有最后一步才返回结果。

注意：JavaScript 没有原生 curry 方法，必须手动实现或借助库（如 Lodash 的 _.curry）。

如何手写一个通用的 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 更省心。