柯里化应精准使用而非滥用：仅在预设参数复用、工具库统一风格、函数式组合、事件处理器绑定上下文时采用；优先选用箭头函数、配置对象、默认参数等更直白方案；限制层级为两层，避免含默认值或rest参数的函数柯里化，公共API慎用，并需注释、类型提示与语义化命名。
柯里化确实能提升函数复用性和组合能力，但实际开发中滥用它会让逻辑变绕、调试变难、协作变卡。避免过度使用，关键不是“少用”，而是“用得准”。
明确哪些场景真需要柯里化
只在以下情况考虑柯里化：
- 需要预设固定参数并多次复用，比如
const logError = curry(console.error)('API')；logError('timeout') - 构建工具函数库时统一接口风格，如 Ramda 或 Lodash/fp 的函数默认柯里化
- 配合函数式组合（
compose/pipe）处理数据流，例如pipe(filter(isActive), map(getName), join(', ')) - 事件处理器中需绑定部分上下文，且后续参数由系统传入（如 React 中
onClick={handleClick(id)}）
优先用更直白的替代方案
多数时候，简单写法更清晰、更易维护：
- 用箭头函数封装：代替
curry(add)(5)，直接写(x) => x + 5 - 用对象方法或配置对象：代替多层柯里化配置，比如
createRequest({ baseUrl: '/api', timeout: 5000 }) - 用默认参数或解构：函数本身支持
function format(date, { locale = 'en', timeZone = 'UTC' } = {}) {...}，就不必柯里化来“冻结” locale
设定团队可接受的柯里化层级
柯里化嵌套越深，理解成本越高。建议约定：
立即学习“Java免费学习笔记（深入）”；
- 最多两层调用（如
f(a)(b)），避免f(a)(b)(c)(d) - 不柯里化含默认值、rest 参数或动态参数的函数（
fn(a, b = 1, ...rest)的length不可靠，柯里化行为易出错） - 公共 API 或跨模块函数不默认柯里化，除非整个项目已采用函数式范式并有配套文档
加注释和类型提示，不靠人猜
一旦用了柯里化，务必显式说明意图：
- 在 JSDoc 中注明“此函数柯里化，用于预设 config”
- TypeScript 下提供完整类型推导，比如
const withApi = curry(<t>(url: string) => (data: T) => fetch(url, data))</t> - 命名体现用途：不用
curriedFilter，而用filterByStatus = curry(filter)(item => item.status === 'active')
