柯里化是函数改造模式，核心为参数复用、延迟配置和组合自由；手写需三步：记参、判长、够则执行否则返新函数；注意fn.length限制及箭头函数无length。
curry 不是语法糖，也不是内置 API，而是一种函数改造模式：把 add(a, b, c) 变成能写成 add(1)(2)(3) 的形式——但它的真正价值，从来不在“看起来高级”，而在**参数复用、延迟配置和组合自由**。
怎么手写一个真正能用的 curry 函数
核心就三件事：记参数、判够不够、不够就再等。别被“递归”吓住，它其实很直白：
-
fn.length是你的尺子——它告诉你原函数声明了几个形参（注意：箭头函数没有length，慎用） - 用闭包存已传的参数，每次调用都
concat新参数进去 - 够数了就
fn.apply(this, args)执行；不够就返回新函数，继续等
实操代码（可直接粘贴进控制台验证）：
function curry(fn) {
return function curried(args = []) {
return args.length >= fn.length
? fn.apply(this, args)
: function(nextArgs) {
return curried.call(this, args.concat(nextArgs));
};
};
}
用它包装 parseInt(str, radix) 就能写出 curry(parseInt)(10)，然后直接传字符串：['1', '2', '3'].map(curry(parseInt)(10))。
柯里化不是 bind，更不是“预填参数”那么简单
常见误解：以为 add.bind(null, 5) 就是柯里化。错。它返回的是 function(b, c) { ... }，一步到位，没法再拆——而柯里化必须保留“还能再收一个”的能力。
立即学习“Java免费学习笔记（深入）”；
-
curry(add)(5)返回的是一个等待b的函数，你还可以curry(add)(5)(10)，再等c -
bind固定的是 this 和部分参数，不关心后续是否还能分步；柯里化强制单参链，天然适配compose、pipe等函数式工具 - React 中绑定事件时，
onClick={curry(handleClick)(id)}比onClick={() => handleClick(id, event)}更轻量——后者每次渲染都新建函数，前者只创建一次
哪些场景真值得用，哪些纯属硬套
柯里化不是银弹，滥用反而让调用链变长、语义模糊。盯住这几个真实痛点再动它：
-
日志/监控封装：比如
log(level, msg)→const errorLog = curry(log)('ERROR')，后续所有errorLog('timeout')都自动带级别 -
API 请求预置：把
fetch(url, options)柯里化后，先固定 base URL 和超时：const apiGet = curry(fetch)('https://api.example.com', { timeout: 5000 })，后面只传具体路径 -
表单验证规则复用：如
validate(pattern, value)→const isEmail = curry(validate)(/^\w+@\w+\.\w+$/)，验证时干净利落 -
避免踩坑：含 rest 参数（
function(...args)）的函数，fn.length === 0，通用curry会失效；需显式传参个数或改用 Lodash 的_.curry(func, arity)
现代项目里，还该自己写 curry 吗
业务代码中，不建议。Lodash 的 _.curry 支持 placeholder、缓存、类型推导；Ramda 的 R.curry 更严格，且默认支持自动柯里化（比如 R.map(fn) 本身就是柯里化的）。手写只适合两种情况：
- 学习原理，搞懂闭包怎么存状态、
length怎么被利用 - 有定制需求，比如要加日志埋点、支持异步函数、或兼容 TypeScript 泛型推导
最常被忽略的一点：柯里化函数一旦生成，就固化了原始函数的 length 行为——如果你后期改了原函数签名（比如从 (a, b) 改成 (a, b, c)），所有已生成的柯里化函数不会自动更新，得重新 curry 一遍。
