柯里化与部分应用本质不同：前者强制单参数链式调用（如f(a)(b)(c)），依赖闭包逐层返回函数，强调可组合性；后者预设任意位置参数（如bind或_.partial），保持原函数调用方式，侧重配置简化。

柯里化和部分应用不是同一件事，但常被混用。简单说：柯里化是“强制单步输入”，部分应用是“提前填几个空”——前者重过程、后者重配置。

柯里化：为什么必须写成 f(a)(b)(c)？

柯里化把 add(a, b, c) 变成只能逐个调用的链式函数：add(a)(b)(c)。它不接受跳步（如 add(a)(b, c)），也不允许合并参数（如 add(a, b)(c)），除非你手写的实现特别宽松。

• 核心机制靠闭包保存已传参数，每次返回新函数，直到参数数量等于原函数的 length
• 典型用途：需要链式组合的场景，比如 log('error')(msg) 或 api('v1')('users')，让配置层级清晰
• 常见错误：误以为 curry(fn)(a, b) 合法——标准柯里化只收一个参数，多传会忽略或报错（取决于实现）
• 性能无实质影响，但过度嵌套（如无限级柯里化）会增加调用栈深度，实际项目中极少需要

部分应用：怎么用 bind 或 Lodash.partial 预设任意位置参数？

部分应用不改变函数“一次接收多少参数”的行为，只是提前塞值。比如 multiply(2, 3, 4)，用 multiply.bind(null, 2) 得到的新函数，后续直接传 (3, 4) 就行。

• 支持任意位置预设：Lodash 的 _.partial(multiply, _, 3, _) 表示“第二位固定为 3”，首尾留空
• 真实场景多见于 API 封装：const apiGet = _.partial(axios.get, { timeout: 5000 })，之后 apiGet('/users') 自动带超时
• 比柯里化更贴近日常习惯，尤其当参数顺序不友好（如回调在前、数据在后）时，占位符 _ 能翻转逻辑
• 注意 Function.prototype.bind 的第一个参数是 this 上下文，若不关心上下文，务必传 null，否则可能意外绑定错误对象

什么时候该选哪个？看函数是否需要“可组合性”

如果你要拼管道（pipeline）、做高阶函数组合（比如 ['1','2'].map(curry(parseInt)(10))），柯里化更自然；如果只是简化重复调用（如固定主题色、默认请求头），部分应用更直接、语义更清。

• React 中事件处理器常用柯里化避免内联箭头函数：onClick={curry(handleClick)(item.id)}，防止每次渲染重建函数
• 但若需预设中间参数（如日志格式器中的时间戳 + 级别），用部分应用配合占位符更灵活：logWithTime = _.partial(logger, _, 'INFO', new Date())
• 两者可共存：先柯里化再部分应用，比如 curriedAdd(5) 既是柯里化中间态，也相当于对首参做了部分应用

function add(a, b, c) {
  return a + b + c;
}

// 柯里化实现（简易版）
function curry(fn) {
  return function curried(...args) {
    if (args.length >= fn.length) return fn(...args);
    return (...nextArgs) => curried(...args, ...nextArgs);
  };
}

// 部分应用（用 bind）
const add5 = add.bind(null, 5); // 相当于 (b, c) => add(5, b, c)

// 或用 Lodash
const add5and10 = _.partial(add, 5, 10); // (c) => add(5, 10, c)

最容易被忽略的一点：柯里化强调“参数齐了才执行”，而部分应用生成的新函数，只要剩余参数给够就立刻执行——这个延迟/即时的语义差异，在调试异步流程或副作用函数时会暴露得很明显。