柯里化是将多参数函数转换为一系列单参数函数的过程，通过闭包累积参数，待参数数≥fn.length时执行；需避免提前调用、正确处理this及默认/REST参数。
JavaScript 中的函数柯里化（currying）不是语法糖，而是通过闭包逐步接收参数、最终执行的模式；它不改变原函数逻辑，但改变了调用方式和时机。
什么是 curry？怎么手动实现一个基础版本
柯里化本质是把接受多个参数的函数，转成一系列只接受一个参数的函数。关键在于「固定部分参数 + 返回新函数」，直到参数数量满足才真正调用原函数。
常见错误是直接返回 fn(...args) 而不是延迟执行，或者没处理参数长度变化（比如原函数有默认参数或 rest 参数）。
- 必须用闭包保存已传入的参数
- 不能提前调用原函数，要等到参数总数 ≥ 原函数的
fn.length（注意：这仅反映形参个数，不含 rest 参数） - 推荐用数组累积参数，避免多次展开影响性能
function curry(fn) {
return function curried(...args) {
if (args.length >= fn.length) {
return fn.apply(this, args);
}
return function (...moreArgs) {
return curried.apply(this, args.concat(moreArgs));
};
};
}
curry 在实际项目中怎么用？哪些场景真有用
柯里化不是炫技，它在「配置复用」「事件处理器预设」「API 封装」三类场景最实在。
立即学习“Java免费学习笔记（深入）”；
- 封装带固定 base URL 的请求函数：
const getApi = curry(fetch)(baseUrl)，后续只需传 path 和 options - React 中给
onClick绑定带 id 的 handler：onClick={curry(handleClick)(item.id)}，避免内联函数导致重渲染 - 日志函数分级：
const warn = curry(console.log)('[WARN]')，后续只传具体消息
注意：如果原函数依赖 this（比如 class 方法），直接 curry 后会丢失上下文，需用 bind 或箭头函数兜底。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
为什么不用 Lodash 的 _.curry？自己写要注意什么边界
Lodash 的 _.curry 支持占位符（_）、自动识别 rest 参数、可配置 arity，但体积大；自己写轻量版时容易忽略这些：
-
fn.length对箭头函数始终为 0，无法靠它判断参数个数 → 必须显式传入期望参数数（arity） - 原函数有默认参数（如
(a, b = 1)）时，fn.length是 1，但实际可能只需传 1 个参数就可执行 → 自定义判断逻辑更稳 - 连续多次调用空参数（
curried()()）应保持等待状态，不能报错或立即执行
简单项目用自实现够用，复杂参数策略建议直接上 _.curry 或 ramda.curry。
柯里化和偏函数（partial application）有什么区别
这是最容易混淆的点：柯里化是「严格逐个收参，每次只收一个，返回新函数」；偏函数是「一次收若干个，剩余参数留空，也返回新函数」。
例如：add(1)(2)(3) 是柯里化；partial(add, 1, 2) 返回能直接调用 (3) 的函数，但也可以 partial(add, 1)(2, 3) —— 它不强制单参。
很多所谓「curry」实现其实是偏函数（比如早期 ES5 工具库），判断依据就看是否强制 fn(a)(b)(c) 形式。真柯里化对组合（compose）和 point-free 编程更友好，但日常开发中偏函数更灵活。
