柯里化函数本质是利用闭包将多参数函数分步接收参数，通过逐层嵌套保存已传参数，直至凑齐才执行，用于解决重复传参、提前配置和逻辑复用等问题。
柯里化函数本质是用闭包把多参数函数“切片”，每次只收一个（或几个）参数，中间状态靠闭包留住，直到凑齐才真正执行。它不是炫技，而是为了解决重复传参、提前配置、逻辑复用这些实际问题。
闭包是柯里化的底层支撑
没有闭包，柯里化就无法保存已传入的参数。每次外层函数执行后返回内层函数，内层函数仍能访问外层作用域里的变量——比如 add(1) 返回的函数记住了 a = 1，等 (2) 进来时直接算 1 + 2。
- 闭包让参数“粘”在函数上，不依赖调用时上下文
- 每嵌套一层，就形成一个新闭包，参数链逐级累积
- 内存中保留的是必要参数，不是整个原始函数调用栈
柯里化让高阶函数更易组合和复用
当函数本身接受另一个函数作为参数（即高阶函数），柯里化能提前固化部分行为，让后续调用更专注核心逻辑。
- 比如 processData(list)(filter)(mapper)，可先固定 filter 得到新函数，再传不同 mapper
- Redux 中 selector 常用柯里化：先传 state 结构路径，再传具体字段，避免每次重复写深层取值逻辑
- 构建数据管道时，每个柯里化步骤只关心自己的输入输出，职责清晰，便于单元测试
实用的柯里化写法不一定要“层层嵌套”
手动写 fn(a)(b)(c) 虽直观，但参数多时难维护。更常用的是带参数收集的通用 curry 工具：
- 接收原函数和已知参数，返回一个能继续收参的新函数
- 内部用 Array.from(arguments) 合并已传和新传参数
- 判断总参数数是否达到原函数的 fn.length，够了就 fn.apply(this, args) 执行
- 不够就递归返回新的柯里化函数，支持 fn(1)(2,3) 或 fn(1,2)(3) 等灵活调用
柯里化不是万能，但适合这几类场景
它解决的是“参数有稳定部分+变动部分”的典型模式，不是所有多参函数都值得柯里化。
- API 请求封装：固定 base URL 和 headers，只变 endpoint 和 payload
- 校验函数工厂：如 isEmail = curry(validate, /^\w+@\w+\.\w+$/)，生成专用校验器
- 事件处理器预设：给 onClick 提前绑定 id 或 context，避免内联箭头函数反复创建
- 避免重复计算：首次传配置对象，后续每次调用只传业务数据，配置解析只做一次
