1. 为什么我盯着自己写了三天的订单代码最终还是推倒重来先说个真实经历。之前我负责一个订单系统的重构需求本身不复杂根据用户等级、订单金额、会员标签、优惠券类型算出最终应付金额再走一遍库存校验、风控校验、日志记录、消息通知。我第一版写得非常工整每个步骤一个函数从上往下依次调用。代码结构长这样先取用户信息再算折扣再判断是否满足免运费再叠加优惠券再检查库存每一步都有 if 分支每两个函数之间还要传一个不断膨胀的上下文对象。代码跑起来没有任何问题测试也全绿。但当我第三天回头想加一个新的会员等级时我发现自己在十几个函数之间来回跳转每次都要重新捋一遍这个函数改了之后谁还会受影响。真正让我决定推倒重来的瞬间是我发现订单金额的计算逻辑散落在五个函数里而其中三个函数修改了同一个对象的字段只是修改顺序被隐藏在调用次序里。这就是典型的命令式思维写出来的代码——每一步都清楚但整体不可组合。后来我换了一种写法核心思想就是函数组合。它属于函数式编程思想里的一个基础操作但带来的改变是结构性的我不再关心每一步怎么执行而是关心这些函数怎么拼起来。每个函数只做一件事输入输出干净函数的拼装顺序就是业务逻辑的顺序任何人拿到这段代码都能像读一条流水线一样读下去。这篇文章我就想聊聊函数组合这件事它的核心概念、它解决了什么问题、在真实项目里怎么落地以及哪些地方我踩过坑。无论你是刚开始接触函数式编程还是已经写过一段时间的 FP 代码但还没有真正体会到组合的威力这篇文章应该都能给你一些可以带回去直接用的东西。2. 组合子和管线组合先把最核心的几个概念弄明白函数组合不是一个高深的东西它就是把两个函数串起来前一个的输出作为后一个的输入。形式化一点组合compose(f, g)等价于先执行g再把结果传给f即x - f(g(x))。如果是从左往右读数据流就有一个与之对称的操作叫pipe即x - g(x) - f(x)。compose 和 pipe 本质上是一个东西只是顺序相反。2.1 用生活中的例子理解 compose 和 pipe你可以把 compose 想成一条食品加工流水线。原料进去第一步清洗第二步切块第三步腌制第四步下锅。命令式写法就是你在每个工位之间手动传递原料洗完了端着盆走到切菜台切完了端着案板走到腌制台。函数组合的写法是把整个流水线本身定义成一个函数cook compose(fry, marinate, cut, wash)之后你只需要调用一次cook(原料)整条线自动跑完。pipe 则是同一件事的另一种读法只是顺序反过来更贴近数据流的方向。洗好的原料流向切菜台切好的流向腌制台腌好的流向炒锅。代码里我会更常用 pipe因为从左往右读代码更符合阅读习惯。pipe(wash, cut, marinate, fry)(原料)一眼就能看出数据经过了哪些加工环节。2.2 组合的前提unary function 和纯函数组合看起来很自然但有一个隐藏前提参与组合的每个函数最好都是一元函数也就是只接收一个参数。如果函数需要两个参数那就没法直接塞进流水线里因为前一个函数只会传出一个结果。解决方式是柯里化currying或偏应用partial application把多参函数变成先收一部分参数返回一个新函数再收剩下的参数。举一个我在业务里常用的场景。要写一个按照指定倍数放大数值的函数如果直接写成multiply(a, b)它就很难参与组合。但你把它柯里化成multiply (a) (b) a * b之后pipe(addTax, multiply(2))这样的组合就成立了。这里multiply(2)返回的是一个把传入值乘以2的一元函数刚好塞进管线。另一个前提是纯函数。所谓纯函数就是同样输入永远得到同样输出并且不修改外部状态。组合本身就是把多个函数连起来只要其中一个函数内部依赖了外部可变状态整个流水线的行为就变得不确定。这个函数在不同时间调用可能产生不同结果组合顺序一旦变化结果也跟着变调试难度成倍上升。所以每一级函数的纯度基本决定了组合的可靠性。2.3 几个手写版本compose、pipe、tap工具库里有现成的但我建议你至少手写一遍理解会更透。下面是两个最简单版本用 TypeScript 写的顺便带上类型// 从右往左执行 export function composeT0, T1, R( f: (x: T1) R, g: (x: T0) T1 ): (x: T0) R { return (x) f(g(x)); } // 从左往右执行 export function pipeT0, T1, R( g: (x: T0) T1, f: (x: T1) R ): (x: T0) R { return (x) f(g(x)); } // 只处理一个值不改变它纯粹用来插入副作用日志、上报等 export function tapT(fn: (x: T) void) { return (x: T): T { fn(x); return x; }; }tap是我在调试和埋点时用得最多的辅助函数。它接受一个只产生副作用但不返回新值的函数组合在管线中间既不破坏数据流又能打印当前状态或者上报日志。比如pipe(getUser, tap(user console.log(user.id)), applyDiscount)在组合的任意位置插一个观察点就能看到数据走到哪一步了这个体验比打断点还舒服。2.4 没有 compose 的世界是什么样为了对比我写一小段真实业务里最常见的中间变量地狱// 命令式版本 function calculateFinalPrice(order) { const user getUser(order.userId); let price order.subtotal; if (user.level vip) { price price * 0.8; } if (user.tags.includes(newUser)) { price price - 20; } if (price 0) { price 0; } if (hasCoupon(order.couponId)) { price applyCoupon(price, getCoupon(order.couponId)); } price Math.round(price * 100) / 100; return price; }这段代码的问题不在于缩进和变量名而在于price这个变量在函数体内被反复重新赋值每个分支都依赖前面的分支是否执行过。你没法单独测试打折之后是否减了20因为整个流程是焊死在这个函数里的。用函数组合重写思路就变成数据流的逐级变换// 组合版本 const calculateFinalPrice (order) getVipDiscount(order) .then(applyNewUserDiscount) .then(clampToZero) .then(applyCoupon) .then(roundToCent);这个版本里每一行就是一级变换每一级都可以单独拿出来测试也可以随时在其中插入 tap 看中间值。这就是让代码更优雅最直观的体现。3. 从理论到可运行代码我用一个订单折扣需求做了次组合式改造上一节的例子有点简化这节我完整还原一次真实改造。需求是这样的一个电商订单在下单时系统需要根据用户的会员等级、订单金额、优惠券和商品品类计算出最终应付金额并且要在日志里记录每一步的计算依据。原来的实现是一个 200 行的 service 方法里面塞了四五个 if-else、两三个 for 循环、一个对象在函数内部被不断修改。3.1 先拆出不可再拆的原子函数改造的第一步不是写组合而是把大函数拆成一个个原子函数。每个原子函数的特征输入输出明确、只做一件事、不修改外部状态。以这个订单计算为例我拆出了这些// 计算会员折扣vip 8折svip 7折 const vipDiscount (user: User) (price: number): number user.level vip ? price * 0.8 : user.level svip ? price * 0.7 : price; // 新用户立减 const newUserDiscount (user: User) (price: number): number user.tags.includes(newUser) ? price - 20 : price; // 价格不能为负数 const clampToZero (price: number): number Math.max(0, price); // 满减券满100减10满200减30 const couponDiscount (coupon?: Coupon) (price: number): number { if (!coupon) return price; if (price 200) return price - coupon.discount200; if (price 100) return price - coupon.discount100; return price; }; // 金额保留两位小数 const roundToCent (price: number): number Math.round(price * 100) / 100; // 记录计算依据 const logCalculation (context: string) (price: number): number { console.log(${context}: ${price}); return price; };注意这些函数都是返回函数的形式也就是柯里化之后的版本。这里有个设计细节值得多说一句user和coupon这些上下文参数被设计成先注入后参与组合。也就是说组合的运行时只传递price一个值上下文通过闭包携带。这样做的好处是vipDiscount(user)返回的是一个纯函数它的行为完全由user决定和组合的先后顺序无关。3.2 用 pipe 拼出业务流水线有了原子函数拼装就非常直观了const buildPricePipeline (order: Order) { const user getUser(order.userId); const coupon getCoupon(order.couponId); return pipe( logCalculation(原始金额), vipDiscount(user), newUserDiscount(user), clampToZero, couponDiscount(coupon), roundToCent, logCalculation(最终金额) ); }; const finalPrice buildPricePipeline(order)(order.subtotal);如果我想加一个生日月双倍积分的折扣只需要新写一个原子函数然后在 pipe 里插一行。不会影响已经存在的任何函数。如果要调整折扣顺序——比如先满减再打会员折——直接把两行换个位置就行每个函数的正确性不受影响因为它们是纯函数。这套写法最大的收益不是代码行数变少而是每一步都可以独立验证。我甚至可以写一个小工具把每一步的名称和结果输出成 JSON 数组直接变成审计日志。这在原来的命令式写法里几乎没法做到因为你很难在不改动原函数的前提下插入中间观测点。3.3 pointfree 风格不提及数据本身如果你接触过函数式编程可能听过 pointfree 这个词。它的意思是写组合的时候代码里不出现数据本身这个变量名。上面例子中pipe(...)(order.subtotal)里order.subtotal出现过一次但如果进一步封装可以写成完全不出现数据变量的形式const finalPrice pipe( calculateBasePrice, // Order - number vipDiscount(user), newUserDiscount(user), clampToZero, couponDiscount(coupon), roundToCent )(order);这里calculateBasePrice从 order 里取出 subtotal后面的所有函数都不再感知 order 的存在。pointfree 的好处是强迫你把函数写成数据进、数据出的形态组合关系更加清晰。但它也有代价一旦中间某一步出错错误信息里就没有变量名可以帮你定位完全靠函数名和类型推断。所以我实际写业务代码时不会刻意追求 100% pointfree而是只在管线较长、步骤较多的时候采用这种风格配合 tap 做调试。4. 异步流程与错误处理函数组合实战中最容易翻车的两个地方上面所有例子都是同步函数但真实项目里大量操作是异步的——查用户要请求数据库算完价格要调用库存服务这些都是 Promise。异步场景下函数组合的玩法和同步略有差别错误处理更是重灾区。4.1 async 函数直接参与组合好消息是async函数天然兼容 pipe。前一个函数返回 Promise后一个函数用await接收只要你不把取 Promise 值和传 Promise 值搞混就能直接组合const fetchUser async (userId: string): PromiseUser api.getUser(userId); const fetchCoupon async (couponId?: string): PromiseCoupon | null couponId ? api.getCoupon(couponId) : Promise.resolve(null); const calcDiscount (user: User) (coupon: Coupon | null) (price: number): number { ... }; const pipeline async (order: Order): Promisenumber { const user await fetchUser(order.userId); const coupon await fetchCoupon(order.couponId); return pipe( vipDiscount(user), newUserDiscount(user), clampToZero, couponDiscount(coupon), roundToCent )(order.subtotal); };这里的关键是异步操作抓取 user 和 coupon尽量放在组合之前完成组合内部只处理纯计算。如果硬要把异步操作塞进组合中间比如先折扣再异步查库存再折扣虽然技术上可行但会让管线里每个函数都变成 async之后所有函数都要 await组合的可读性会明显下降。我的一般原则是IO 边界放两头中间保持纯同步。4.2 用 Result 类型替代 try-catch 地狱组合链上如果某个同步函数可能抛异常直接用 try-catch 包裹整个管道其实是可行的但那会让错误处理变得粗粒度你不知道是哪一步抛的。更函数式的做法是给管道里的每一步包一层 Result 类型把异常显式地变成失败值。最简单的 Result 实现不需要引库type ResultT | { ok: true; value: T } | { ok: false; error: Error }; const tryCatch T(fn: () T): ResultT { try { return { ok: true, value: fn() }; } catch (error) { return { ok: false, error: error as Error }; } }; // 组合链上某个环节可能会失败时 const calculateResult (order: Order): Resultnumber pipe( tryCatch(() getUser(order.userId)), map(user vipDiscount(user)), map(applyNewUserDiscount), map(clampToZero), map(roundToCent) )(order);注意这里只在最外层包了一次 tryCatch内部通过map把纯函数映射到 Result 上。这其实就是 Either 的简化版。用这种方式错误不会在链上炸开而是作为值一路传递。最后判断result.ok就知道整条链有没有失败。这个模式最大的价值是错误变成了一个可以被组合的值。你可以继续pipe它比如在失败时补一个默认值const orElse T(fallback: T) (result: ResultT): T result.ok ? result.value : fallback; const finalPrice pipe(calculateResult, orElse(0))(order);在日志系统里这种写法特别顺手。成功和失败走不同的观察函数但组合结构完全不变。4.3 Promise.all 和组合怎么配合如果管道里有多个互不依赖的异步数据源可以用Promise.all并行获取再统一进入组合const [user, coupon, stock] await Promise.all([ fetchUser(order.userId), fetchCoupon(order.couponId), fetchStock(order.skuId), ]); const finalPrice pipe( vipDiscount(user), couponDiscount(coupon), clampToZero, roundToCent )(order.subtotal);顺序组合解决的是数据依赖问题并行获取解决的是数据无关问题。两者搭配是这个场景下的标准解法。我见过不少异步流水线是一步一个 await把本来可以并行的查询硬生生串行执行这种方式在函数组合的框架下很容易被识别出来——因为你会发现某两个函数之间根本没有数据依赖它们完全可以并行。5. 类型安全视角让 TypeScript 帮你兜住组合的底函数组合在 JavaScript 里很灵活但也正因为灵活拼错函数顺序时经常要到运行时才能发现。TypeScript 可以帮我们把相当一部分组合错误提前到编译期。5.1 为 pipe 和 compose 标上完整类型手写一个支持多函数的 pipe 类型不算难关键是让每个函数的输入类型和上一个函数的输出类型对齐。完整版如下type AnyFn (...args: any[]) any; export function pipeA, B( f: (a: A) B ): (a: A) B; export function pipeA, B, C( f: (a: A) B, g: (b: B) C ): (a: A) C; export function pipeA, B, C, D( f: (a: A) B, g: (b: B) C, h: (c: C) D ): (a: A) D; export function pipe(...fns: AnyFn[]) { return (initial: any) fns.reduce((acc, fn) fn(acc), initial); }写完之后如果你不小心把vipDiscount和roundToCent的顺序调反了roundToCent 输出 number而 vipDiscount 期望接收 number但入股顺序反了vipDiscount 接收的就是 number其实问题不一定暴露更常见的错误是把一个本来期望User的函数放在期望number的函数后面TS 会直接在pipe(...)那一行标红。这个体验比运行时崩溃好太多。5.2 类型收窄与 function composition 的碰撞TS 的类型收窄narrowing在命令式代码里靠typeof或if判断来实现但在函数组合链上没法写 if所以收窄逻辑要封装进函数内部。比如一个处理字符串或数字的管道const toString (x: string | number): string typeof x number ? x.toFixed(2) : x; const toLength (s: string): number s.length; const result pipe( toString, // string | number - string toLength // string - number )(input);这种设计模式叫类型边界函数在管线入口处做一次类型收窄把联合类型变成单一类型后续函数就全部处于安全区。如果直接在管线中间做 typeof 判断会破坏 pointfree 的结构而且类型上很难表述。所以我的经验是任何联合类型都尽量在管线的第一格处理掉不要让联合类型在管线中传播。5.3 组合函数时返回类型的可追踪性还有一个容易被忽略的好处函数组合的返回类型是明确的这在重构时特别有用。你可以在不运行代码的情况下只通过类型推断看出某个管道最后返回的是一个Resultnumber还是一个PromiseUser。我在重构遗留代码时会把大函数拆成原子函数后用 pipe 重拼这一步对类型的要求几乎是白送的——TS 会在我拼装的每一个断点告诉我数据类型对不对不用靠 console.log 去摸。6. 组合思维在真实项目中的延伸从函数到组件到业务编排函数组合不只体现在纯函数上。一旦你习惯了这种思维你会发现很多编程场景本质都是组合React 组件的嵌套、中间件模型、装饰器模式、策略模式的配置化实现甚至状态管理的 reducer 也是组合。6.1 React 组件级别的组合React 从设计上就是组合式的。函数组件本身是props - ReactNode的纯函数高阶组件HOC则可以看作函数组合器const withAuth (Component) (props) { const user useAuth(); return Component {...props} user{user} /; }; const withLogger (Component) (props) { useEffect(() { console.log(render, Component.name); }, [props]); return Component {...props} /; }; const EnhancedComponent withLogger(withAuth(OrderCard));这与compose(withAuth, withLogger)(OrderCard)的逻辑完全一致一层一层套每层只负责一件事。Hooks 出现之后HOC 的使用变少了但数据从哪来、行为怎么加的组合设计思想并没有消失只是从组件嵌套变成了自定义 Hook 的组合。本质上依然是一个函数接收一个 Hook 的返回值输出一个新的值给下一个 Hook。6.2 微服务与服务编排的流程组合如果你做过微服务会发现服务编排本质也是函数组合取用户、查订单、调库存、记日志每个服务调用就是一个函数服务之间的依赖关系就是管线顺序。区别在于函数组合是同步代码块之间的连接而服务编排需要在网络上做同样的连接所以出现了编排层这种专门的中间层。理解了函数组合你就理解了为什么编排引擎的 DSL 看起来那么眼熟——retry、timeout、fallback 本质上就是组合子。6.3 组合子和装饰器原来是同一个东西在面向对象世界里装饰器模式给对象动态加职责在函数式世界里高阶函数包裹函数、添加行为两者结构一模一样。withLogger包裹组件和tap包裹计算函数干的是同一件事在不改原实现的前提下注入横切逻辑。我在设计一个通用上报 SDK 时就用 pipe tap 把埋点逻辑插进了核心管线的每一步而 SDK 的使用方完全无感知。这种横切能力命令式代码要借助 AOP 框架才能实现函数组合里用一个 tap 就解决了。7. 什么时候坚决不要用函数组合以及我怎么给组合代码写测试函数组合不是银弹。这篇写到最后我想坦诚聊聊它的边界以及我在实际项目中踩过的坑。7.1 别为了组合而组合如果一个函数本身就三步以下、没有复用需求、调用方只有一个硬拆成 pipe 反而会降低可读性。比如const total items.reduce((sum, i) sum i.price, 0)完全没必要拆成pipe(getPrices, sum)(items)。组合的价值在于复用、可测性和可观测性如果这三样都用不上组合只会增加不必要的心智负担。另一个不该用组合的地方是团队整体还没建立起函数式思维的时候。我自己经历过一个项目核心模块用管道写得非常漂亮但其他同事维护时对pipe里的函数行为把握不准又觉得反正就是一个链子我改一下中间这个函数没关系结果破坏了上游函数对数据格式的假设。组合代码对团队的要求其实更高——你要求每个成员都能理解数据流经每一级时发生了什么。如果你的团队更习惯命令式强行上组合风格维护成本可能反而更高。7.2 深组合会不会爆栈性能问题怎么看compose 嵌套的层级如果非常深比如成百上千层确实可能带来调用栈压力。但在业务代码里一个管道通常 5 到 15 个函数完全不会碰到栈上限。性能方面纯函数 组合对现代 JIT 引擎非常友好因为函数边界清晰、类型稳定V8 可以优化得很激进。真正影响性能的是函数内部做了 IO 或大量计算和组合本身无关。我做过一次粗略对比100 万次 10 级 pipe 调用耗时比手写循环版多不到 5%在绝大多数业务场景里可以忽略不计。不过有一个性能坑必须提柯里化 闭包可能带来额外的对象分配。如果你在热路径上频繁创建管道里的中间函数比如每秒执行百万次的场景建议把预注入参数的函数提到模块顶层避免每次执行都重新创建一遍。我的一般原则是管道工厂函数只在业务入口调用不在内层循环里调用。7.3 给组合代码写测试的三种技巧组合代码的测试其实比命令式更容易因为每一级都是独立纯函数。我常用的测试策略有以下三种。第一原子函数单测。这是重中之重每个原子函数输入输出简单测试用例批量写即可。比如clampToZero我测负值、零、正值三组完了。第二管线集成测试。用一个完整输入跑整条管道验证最终结果。这相当于命令式代码里的大函数测试但因为每一步能被 tap 插桩测试失败时能精确定位到哪一级。const trackablePipeline pipe( tap(price expect(price).toBe(100)), vipDiscount(user), tap(price expect(price).toBe(80)), roundToCent );第三快照测试。把每一步的中间结果收集成数组和上一次的运行结果做快照对比。这个对计算依据审计特别有用一旦某一步逻辑变了快照会立刻告诉我影响范围。7.4 调试组合代码的几条经验最后聊聊调试。组合代码最大的调试痛点是一旦结果不对你看不到中间值。我的标准做法是两个面向一是多用tap。项目里维护一个日志统一的 tap 工厂接受一个字符串标识输出当前值。管线里每个关键节点都先插上 tap跑完看日志再决定这一年哪一级改错了逻辑。定位完之后留着还是删掉按需处理但 tap 本身不会干扰数据流留几个也无妨。二是用命名函数而不是匿名箭头函数。在 pipe 里写x x * 0.8和写vipRate前者在堆栈里显示为匿名函数后者能直接看到函数名排查调用栈的效率完全不同。三是不要羞于临时改成命令式。如果一条管道怎么都调不对我会临时把它展开成一步步的变量赋值逐行 console.log等定位到问题再还原回组合写法。工具是为人服务的没必要为了风格上的纯粹折磨自己。最后说点实在的函数组合真正让我上瘾的地方不是它让代码变短而是它改变了我的思考方式从一个函数里堆积多个步骤变成把多个函数串成一条清晰的数据流。这种转变带来的不只是代码更优雅更是调试、测试、复用、审计这一整套开发体验的全面提升。如果你现在正在写一段 100 行以上、里面塞满了 if 分支和中间变量的函数不妨停下来想一想能不能把它拆成 5 个纯函数然后用 pipe 串起来。你可能只需要多花半小时但接下来维护这段代码的每个人都会感谢你。我个人在实际项目里已经离不开 pipe 和 tap 这两个工具函数了几乎每个模块都会用到。如果你还没有自己的工具库从这两个函数开始建立基本不会错。