健壮的 compose 函数应支持单参数、不修改原函数、透传非函数值，核心实现为 const compose = (...fns) => (x) => fns.reduceRight((acc, fn) => typeof fn === 'function' ? fn(acc) : acc, x)。
compose 函数怎么写才真正可用
直接用 compose 实现函数组合，核心就一条：从右到左执行，上一个函数的返回值是下一个函数的输入。但很多人写的 compose 在遇到异步、空值、错误时立刻崩——不是语法错，是逻辑没兜住。
一个健壮的 compose 至少要满足三点：支持单参数（避免歧义）、不修改原函数、能透传非函数类型的中间值（比如 null 或 Promise）。下面这个版本在 TypeScript 项目里跑过半年，没出过意外交互：
const compose = (...fns) => (x) => fns.reduceRight((acc, fn) => (typeof fn === 'function' ? fn(acc) : acc), x);
-
reduceRight确保顺序是 f3(f2(f1(x)))，不是反的 - 加了
typeof fn === 'function'判断，防止配置项误传成函数导致TypeError: fn is not a function - 不强制要求每个函数都返回值，
undefined会原样往下传，方便调试时插日志函数
和 pipe 的区别不是“左右”而是使用意图
有人纠结该用 compose 还是 pipe，其实关键不在执行方向，而在你读代码时想强调什么。比如处理用户输入：
const sanitize = x => x.trim(); const toInt = x => parseInt(x, 10); const clamp = x => Math.max(0, Math.min(100, x));
如果写成 compose(clamp, toInt, sanitize)(input)，你得从右往左读才能理解流程；而 pipe(sanitize, toInt, clamp)(input) 更贴近自然语言：“先清理，再转数字，最后限制范围”。
- 团队统一用
pipe更易维护，尤其当函数链超过 4 个时 - Redux 的
compose是历史包袱，它把中间件、store enhancer 套在一起，但业务逻辑别学它 - 注意：Lodash 的
flow就是pipe，flowRight才是compose，别被名字骗
async/await 场景下 compose 会静默失败
这是最常踩的坑：compose 本身不关心 Promise，但它会把 Promise 当普通值传给下一个函数，结果就是下一个函数收到的是 pending 状态对象，而不是解包后的值。
解决方法不是重写 compose，而是提前归一化异步行为：
- 所有异步函数统一用
async声明，哪怕只是async () => x - 组合前用
Promise.resolve包一层初始值：compose(f3, f2, f1)(Promise.resolve(x)) - 更稳妥的做法是拆开写：
const result = await f1(x); await f2(result); await f3(result)—— 复杂流程别硬塞进 compose
强行搞 “async compose” 容易让错误堆栈变模糊，debug 时找不到哪一步 reject 的。
React 中 useReducer + compose 的实际约束
有人想把 reducer 拆成小函数再用 compose 组装，比如 compose(handleLoading, handleSuccess, handleError)。这在概念上很美，但 React 的 useReducer 要求 reducer 必须是纯函数且返回新 state，而 compose 返回的函数无法被 React 依赖追踪识别。
- reducer 内部可以调用组合好的函数，但不要把
compose(...)结果直接当 reducer 传给useReducer - 状态更新必须显式 return，不能依赖中间函数的副作用（比如某个函数里直接改了 state 对象）
- 如果要用组合逻辑，建议封装成自定义 Hook，把
compose结果藏在闭包里，对外只暴露 action handler
函数组合不是银弹，它适合数据转换类逻辑，不适合状态协调或副作用调度。什么时候该停手？当你开始给 compose 加 try/catch、log、loading 状态时，说明它已经超纲了。
