compose执行顺序为从右到左，即compose(f,g,h)(x)等价于f(g(h(x)))，源于数学函数复合定义；它要求函数纯、一元、同步，且类型严格对齐，否则链式调用会静默崩塌。
函数组合（compose）不是语法糖，而是把“拆得散”和“连得稳”同时做好的关键机制；它本身不解决业务逻辑，但一旦用错顺序、混用副作用或忽略类型对齐，业务流就会在看似干净的链式调用里静默崩塌。
为什么 compose 的执行顺序是「从右到左」而不是直觉的从左到右
这是最常让人卡住的点：你写 compose(f, g, h)(x)，实际执行的是 f(g(h(x)))。原因在于数学上函数复合的定义就是 (f ∘ g ∘ h)(x) = f(g(h(x)))，而 compose 是对这一定义的直接映射。
- 如果强行按从左到右理解，会误判中间值形态——比如
h输出一个对象，但g期待字符串，错误会在运行时才暴露 - Lodash 的
flow是从左到右的替代方案，但标准函数式库（如 Ramda、fp-ts）默认坚持数学惯例 - 调试时建议把组合式展开为嵌套调用临时验证：
f(g(h(x)))比compose(f,g,h)(x)更容易定位哪一层输出异常
如何确保每个函数都真正「单一职责」且可组合
能塞进 compose 的函数必须满足三个硬约束：纯函数、一元输入、同步返回。任何违反都会让组合体变成黑盒。
- 有副作用（如发请求、改全局状态）的函数必须先用
Promise或Task封装，否则compose无法等待异步完成 - 接收多个参数的函数需用柯里化预置参数，例如
mapWith(key)(list)而非mapWith(list, key) - 返回值类型必须向下兼容：前一个函数的输出类型 = 后一个函数的输入类型；TypeScript 下建议用泛型标注，如
const validate: (x: unknown) => Result<user string></user>
遇到「中间值结构不匹配」时怎么快速修复
典型现象是组合链某处报错 Cannot read property 'xxx' of undefined，本质是上游函数返回了意外结构（如 null、{} 或未解构的 Promise）。
- 优先加防御性适配层，而不是修改原函数：写一个
guard函数包裹可能出错的环节，统一返回Result或Option - 避免在组合链中做条件分支（如
if/else），改用chain（Monad）或alt（Alt）这类组合子处理失败路径 - 调试技巧：在怀疑节点插入
tap(console.log)（Ramda）或自定义logStep函数，注意它必须返回原值而非undefined
真正难的从来不是写出 compose(a,b,c)，而是当某个函数悄悄依赖了外部状态、或某次 API 响应结构变更、或团队新人往链里塞了一个带 console.time 的调试函数时，整个业务流依然保持可预测——这要求组合的每个环节都像齿轮一样严丝合缝，且所有齿形（类型、契约、边界）都被显式声明。
