柯里化是通过闭包固定部分参数、延迟执行剩余部分的实用机制，非语法糖；核心是fn(a)(b)(c)式分步调用，依赖fn.length判断执行时机，支持多参数传入与this绑定。

curry 不是语法糖，也不是炫技工具——它是你提前“钉住”某些参数、让函数更易复用的实用机制。

什么是 curry？它和普通函数调用到底差在哪？

简单说：curry 把 fn(a, b, c) 变成可以分步调用的 fn(a)(b)(c)，但关键不是“拆写法”，而是“固定一部分、延迟执行剩余部分”。

• 它依赖闭包保存已传参数，不是靠 arguments 临时拼接
• fn.length 是判断是否该执行的唯一可靠依据（箭头函数没 length，不能直接柯里化）
• 一次传多个参数也合法（比如 curried(1, 2)(3)），这是工程中真正好用的“非严格柯里化”

怎么手写一个靠谱的 curry 函数？

下面这个版本经实战验证，兼容性好、逻辑清晰、支持 this：

function curry(fn) {
  return function curried(...args) {
    if (args.length >= fn.length) {
      return fn.apply(this, args);
    }
    return (...moreArgs) => curried.apply(this, [...args, ...moreArgs]);
  };
}

• 用 rest 参数 ...args 替代老旧的 arguments，避免箭头函数陷阱
• 返回的是箭头函数，自动绑定上层 curried 的 this，比嵌套 function 更简洁
• 不手动递归构造函数链，靠闭包 + 高阶返回自然形成“参数累积”效果

哪些场景真能省事？别硬套，看这三类典型用法

柯里化的价值不在“看起来函数式”，而在解决具体痛点：

• API 封装复用：比如 const githubApi = curry(fetchApi)('https://api.github.com', 5000)，之后所有调用都自带 baseURL 和 timeout
• 事件处理器去内联：React 中写 onClick={handleClick(userId)} 比 onClick={() => handleClick(userId)} 更安全，避免每次渲染都新建函数
• 验证/转换工具链：如 const isEmail = curry((re, str) => re.test(str))(/^[^\s@]+@[^\s@]+\.[^\s@]+$/)，生成即用、语义清晰

容易踩的坑：为什么有时柯里化后反而更难懂？

不是所有函数都适合柯里化，尤其要注意：

• Math.max、console.log 这类接受任意多参数的函数，柯里化后会破坏直觉（curry(Math.max)(1)(2)(3) ≠ Math.max(1,2,3)）
• 原函数若含默认参数（(a, b = 10)），fn.length 仍为 2，但实际可能只需传 1 个——这时柯里化行为与预期不符
• 调试时堆栈变深，错误定位更绕；生产环境建议只对明确需要“预设+复用”的函数柯里化，而非全局批量处理

柯里化的本质不是让调用变长，而是让配置变稳、让组合变轻。一旦你开始反

复写 someFn(x, y, z, ...staticOptions)，就该考虑把它交给 curry 了。