柯里化是将多参数函数转为单参数函数链的过程，核心是延迟求值与参数分批注入；它不等于箭头函数嵌套，关键在依据fn.length自动判断参数是否收齐，且需处理默认参数导致length失真的问题。
什么是柯里化，它和普通函数调用到底差在哪
柯里化不是语法糖，是把 add(a, b, c) 拆成 add(a)(b)(c) 的过程，核心在于“延迟求值”和“参数分批注入”。它不改变逻辑，但改变了你控制执行时机的能力。
常见错误是以为只要用箭头函数嵌套就是柯里化——其实关键在自动推导参数数量。手写时容易漏掉边界判断，比如 curry(add)(1)(2) 应该返回 3，而不是一个等待第三个参数的函数。建议用 lodash.curry 或自己实现时严格校验 fn.length（原函数形参个数）。
- JavaScript 中
Function.prototype.length只统计非默认参数，带默认值的函数会少算，慎用于自动柯里化 - 柯里化后函数不再能用
arguments，要用剩余参数...args显式收集 - 调试时堆栈更长，Chrome 控制台里看到一串
bound或curried是正常现象，别误判为内存泄漏
compose 和 pipe 的区别，为什么选 compose 写链路
compose(f, g, h) 等价于 f(g(h(x)))，从右往左执行；pipe(f, g, h) 是 h(g(f(x)))，从左往右。函数式链路强调“数据流方向”，而 compose 更贴近数学函数复合习惯（(f ∘ g)(x) = f(g(x))），读起来也更顺：你一眼能看出最外层是最终处理者。
容易踩的坑是混淆执行顺序导致逻辑翻转。比如想把字符串转大写再截取前 3 位，写成 compose(take(3), toUpper) 才对；若错用 pipe，就会先 take(3) 再 toUpper，但输入可能还没转大写。
- Redux 的
compose是经典实现，只支持同步函数，不处理 Promise —— 需要异步链路得自己封装asyncCompose或用Promise.then接入 - 所有参与
compose的函数必须是一元函数（只接收一个参数），多参数函数必须先柯里化，否则中间值传不下去 - 调试困难：错误堆栈指向
compose内部，建议开发期用console.log包一层中间函数，或用tap工具函数临时拦截
如何让柯里化 + compose 真正落地到业务逻辑链路
真实场景里，链路不是纯数学运算，常混着副作用、条件分支、异步请求。直接堆 compose 会僵硬。关键是把“可组合单元”定义清楚：每个函数只做一件事，输入输出类型一致（如都操作 user 对象），失败时统一返回 undefined 或抛出 Error（别混用）。
示例：处理用户登录态校验链路
const validateToken = curry((rules, token) => rules.some(r => r.test(token)));
const fetchUser = curry((api, token) => fetch(api + '?token=' + token).then(r => r.json()));
const enrichWithProfile = user => ({ ...user, lastLogin: Date.now() });
// 组合时确保每步输出是下一步输入
const loginFlow = compose(
enrichWithProfile,
fetchUser('/api/user'),
validateToken([/^[A-Za-z0-9]+$/])
);
- 避免在
compose链里写 if/else，改用either模式（如ifElse(isValid, fetchUser, throwError)）保持纯度 - 状态类操作（如 localStorage 读写）必须抽离为独立柯里化函数，不要塞进主链，否则测试和复用全崩
- TypeScript 下记得给每个函数标注完整类型，尤其柯里化后类型推导易断，
ReturnType<typeof fetchuser></typeof>很可能不是你想要的 Promise 类型
性能与可维护性的真实代价在哪里
每次柯里化都新建闭包，每次 compose 都生成新函数——在高频调用场景（如 React render 函数内反复调用）会造成明显 GC 压力。这不是理论风险，V8 的 profiler 能直接抓到 bound 函数堆积。
更大的隐性成本是团队理解门槛。一个新人面对 compose(f, g, h)(x) 不如看 h(g(f(x))) 直观。除非整个代码库已统一函数式风格，否则强行推广柯里化+compose 反而降低可维护性。
- 生产环境慎用动态柯里化（如根据 config 生成 curry 函数），编译期无法优化，Tree-shaking 也剔不掉
- 单元测试必须覆盖“中断链路”的情况，比如
fetchUser抛错时，enrichWithProfile是否被跳过——这靠肉眼很难验证 - 调试时 Chrome 的 “Blackbox” 功能建议打开，把
lodash.curry和compose相关文件加进去，不然断点全卡在工具函数里
