JavaScript柯里化核心是按需选择实现路径：参数预设用闭包、动态长度用fn.length、工程化推荐工具函数而非原型扩展，并区分柯里化与偏应用的单参链式契约。
JavaScript 中柯里化函数在函数扩展中，核心不是“选模式”，而是明确目标后再匹配实现路径——是追求参数预设的简洁性，还是需要动态参数长度支持，抑或强调与现有工具链兼容。不同场景下，适用的扩展方式差异明显。
按需固定参数：用闭包封装最直接
当业务逻辑中某些参数长期不变（比如 API 基础 URL、默认重试次数、固定税率），适合手写单层闭包柯里化。它不依赖函数参数个数判断，语义清晰，调试友好。
- 写法示例：
const fetchUser = baseUrl => id => fetch(`${baseUrl}/users/${id}`) - 调用自然：
fetchUser('https://api.example.com')(123) - 优势：无运行时参数检查开销，执行快，容易单元测试
通用自动柯里化：基于 fn.length 动态适配
若要复用同一套柯里化逻辑处理任意多参函数（如 add(a,b,c)、join(separator, ...items)），必须依赖 fn.length 获取形参个数，并通过递归或累积收集参数。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 关键点：每次调用只收部分参数，不足时返回新函数；凑齐后才真正执行原函数
- 注意：
fn.length不反映实际传参个数（箭头函数、rest 参数会影响），需配合文档或类型约束使用 - 典型实现会用数组
concat或 ES6 展开运算符合并参数
原型扩展 vs 工具函数：工程权衡点
是否往 Function.prototype 上挂方法，本质是团队规范问题。扩展原型虽调用简短（add.curry(2)），但存在污染全局、与第三方库冲突风险。
立即学习“Java免费学习笔记（深入）”；
- 推荐做法：封装为独立工具函数
curry(fn)，显式导入使用 - 如项目已用 Ramda 或 Lodash-fp，直接用
R.curry更稳妥，避免重复实现 - 若坚持原型扩展，务必加防护（如仅在未定义时添加，且命名带前缀如
_curry）
与偏应用（Partial Application）不混淆
柯里化要求严格按序、逐个接收单参数，而偏应用允许一次传多个剩余参数。两者目的相似，但契约不同：
- 柯里化：
add(1)(2)(3)✅，add(1,2)(3)❌（除非实现兼容） - 偏应用：
partial(add, 1)(2, 3)✅，更灵活但丢失“单参链式”语义 - 实际开发中，多数场景用偏应用更实用；柯里化更适合函数组合、管道式编程等 FP 场景
