真正支持多参数分批调用的柯里化需动态判断参数是否收齐：用 fn.length 获取形参个数，闭包累积参数，达标后执行；须用普通函数（箭头函数无 length/arguments）；不支持 rest 参数需额外处理；lodash 加 placeholder（如 _）实现参数占位，提升业务灵活性。
curry 函数怎么写才真正支持多参数分批调用
柯里化不是简单地把 add(a, b, c) 拆成 add(a)(b)(c)，关键在于「自动判断参数是否收齐」。如果硬编码只接受 3 个参数，那遇到 add(1)(2, 3) 或 add(1, 2)(3) 就会出错。
正确做法是让函数持续收集参数，直到总数满足原函数的 length（形参个数），再执行。但要注意：箭头函数没有 arguments 和 length 绑定，所以必须用普通函数；Function.prototype.length 只反映声明时的形参个数，不包含 rest 参数（...args）。
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));
};
};
}
- 用
fn.length判断是否“够数”，不是靠预设数字 - 每次调用都返回新函数，闭包
保存已传参数
-
apply(this, ...)保证原始函数的this上下文不丢失 - 不支持 rest 参数的函数（如
(a, b, ...rest) => {}）会误判length === 2，需额外处理
为什么 lodash 的 curry 要加 placeholder（占位符）
真实场景中，你经常需要跳过某个参数先传后面的，比如 _.curryRight(format, _, 'USD')(1234.56)。原生实现不支持“留空”，因为 curry(add)(1)(undefined)(3) 会被当作传了 undefined，而不是占位。
lodash 用 _ 占位符解决这个问题，内部维护一个标记数组，在最终调用前过滤掉占位符，再按顺序填充真实参数。
- 没占位符时，
ajax(url)(data)(callback)必须严格按序调用 - 有占位符后，可写成
ajax(_, _, headers)(url)(data)，适合配置复用 - 占位逻辑增加复杂度，但换来的是更贴近实际业务的灵活性
柯里化在 React 中最实用的三个地方
不是为了炫技，而是解决具体痛点：事件处理器绑定、高阶组件参数预置、useCallback 防止重复创建。
- 给
onClick传带参数的 handler：onClick={handleClick(id)}每次渲染都新建函数 → 用onClick={curry(handleClick)(id)}，但注意：必须提前 curry，不能在 render 里调curry()，否则每次都是新函数 - HOC 封装时固定部分参数：
withApi(apiConfig)(Component)，比写withApi(Component, apiConfig)更符合组合习惯 - 配合
useCallback缓存：若fetchUser是柯里化函数，useCallback(fetchUser(userId), [userId])才真正依赖稳定
性能和调试上最容易被忽略的坑
柯里化本身开销很小，但副作用常被低估：闭包链变长、堆内存占用上升、Chrome DevTools 中函数名显示为 curried 或 anonymous，断点难定位。
- 不要对高频调用函数柯里化（如每帧执行的 canvas 渲染逻辑），避免闭包累积
- V8 对多次嵌套函数调用有优化限制，超过 10 层可能退化为解释执行
- 错误堆栈里看不到原始函数名，建议在开发环境给柯里化函数加
displayName（React）或用Object.defineProperty(fn, 'name', {...})补充 - TypeScript 类型推导对深度柯里化支持有限，
curry(fn)很容易变成any，需手写泛型重载
