从compose到组合上下文：函数组合的工程化实战复盘

函数组合不是新东西但真正把它做到极致和优雅我用了将近一年的时间反复打磨。这篇文章是我对这段时间的完整复盘。我不打算讲枯燥的范畴论也不打算罗列一堆库的API我想说的是我如何从一个只会写compose(f, g, h)的人逐步走到用组合上下文编排27个节点的真实业务链路。过程中踩过的坑、推翻的设计、留下的工具都在这里。1. 从一行compose到组合上下文我踩过的两个大坑函数组合的入门门槛极低低到很多人觉得它不过是个语法糖。但真正进入实战你会立刻撞上两个墙一个是异步边界怎么跨另一个是数据流怎么穿越多层函数。这两个问题不解决compose只能停留在玩具阶段。1.1 第一个坑异步函数把组合链切成一段一段先说我最早犯的错误。我一度以为组合就是把函数串起来每个函数同步返回结果就好。等到第一个带网络请求的函数出现我发现链路直接断掉——f(g(x))里g返回的是Promisef拿到手的是一个pending状态整个链路瞬间失去语义。当时我手忙脚乱地给每个函数套async/await结果组合链变成了这样const result await f(await g(await h(x)));这根本不是组合这只是把嵌套写了三遍。代码一多人眼根本无法分辨哪一层先执行、哪个await属于哪个函数。更讽刺的是这种写法还让组合的所有优点——可读性、复用性、可替换性——全部消失。我意识到只要异步边界处理不好组合在真实项目中就永远只能是一种书面优雅。解决思路不是回避异步而是让组合子从第一天起就把Promise当成一等公民。所有函数统一返回Promise组合器内部自动处理拍平。这样写出来的链路是这样的const flow composeAsync(validateInput, calcPrice, applyDiscount, buildQuote); const quote await flow(input);每个函数依然只关心自己的入参出参不再需要关心自己的上游是不是异步。这一改组合链终于在异步代码里活了下来。1.2 第二个坑参数形状不一致组合根本拼不起来异步问题刚解决第二个坑立刻浮现真实业务里的函数签名千奇百怪根本不是(a) b这种同构形状。举个我实际遇到的例子。某个订单处理链路里有三个函数getUserOrders(userId)返回订单列表filterActiveOrders(orders)需要订单列表输出活跃订单calcTotal(activeOrders)需要活跃订单输出总金额。看起来形状一致但真实场景根本不是这样。真实场景里还有一个getUserProfile(userId)要并行取用户资料还有一个applyMemberDiscount(profile, total)同时依赖 profile 和 total。这时compose的传统假设——每个函数的输出恰好是下个函数的输入——立刻崩溃。你需要一个能处理一个函数依赖多个上游结果的组合机制。我一开始试图用柯里化硬凑把applyMemberDiscount(profile)变成一个新函数再接入链。结果就是配置越来越繁琐组合链路被各种partial application糊满了。我在一个真实项目里试过一个中等复杂的链路光柯里化包装就写了十几个中间函数代码量不降反升。1.3 破局思路从串联工具转向上下文编排这两个坑把我逼到了一个关键转折点我开始意识到函数组合要真正进入实战不能只是做一个把函数串起来的工具。它必须成为一种编排机制——能处理异步、能按上下文取参、能表达分支和并发、能让数据流显式可见。于是我把重心从改进compose的写法转向设计一套组合上下文。组合上下文的核心就一句话**函数不直接互相调用而是通过一个显式的上下文进行数据交换。**每个函数声明自己需要什么、产出什么组合器负责把上下游接起来。这套设计让我后面所有工作都有了统一底座。下面我分几章把关键设计逐步摊开。为了理解方便先给一个极简版实现作为引子后面章节会解释为什么这样设计function createRuntime() { const env new Map(); // 上下文存储 const registry new Map(); // 函数注册表 function register(name, fn, { reads [], writes [] } {}) { registry.set(name, { fn, reads, writes }); } async function run(node, payload) { const meta registry.get(node.fn); const input { ...payload }; for (const key of meta.reads) input[key] env.get(key); const output await meta.fn(input); for (const key of meta.writes) env.set(key, output[key]); return output; } return { register, run, env }; }这段代码极端简化但已经包含了上下文编排的所有关键元素注册、读依赖、写依赖、运行。真实版本要复杂得多但骨架就是它。2. 编排器的核心设计组合子声明式组合与歧义决策这一章我展开讲讲编排器本身的设计。很多人以为编排器是个复杂的执行引擎其实它最难的部分不是跑而是如何描述。2.1 通过声明式配置描述链路现代前端开发已经普遍认同组件化思维但函数层的组合很多人还停留在写工具函数的层面。我在项目里引入的是一个通用函数组合工具它自己就是一个函数容器核心逻辑是解析函数签名、根据定义描述组合关系、统一调度执行。这套通用函数组合工具我之前在文章里详细拆过实现这里不重复只提几个关键设计点组合顺序与执行顺序一致。我习惯用compose表示从右到左的惰性组合pipe表示从左到右的立即执行。这个区别很重要后面会专门讲。组合子一律返回Promise值统一用不可变结构包裹。这样所有函数在接口上完全同构组合时不需要关心中间函数是否异步序列化、调试、缓存都统一了。每个组合子内部都带位置元信息报错时候能直接告诉你链路第3步alias函数出错。这个能力在长链路排查时非常关键。设计细节用一个例子说明。假设要做一个会员订单金额汇总第1步输入订单列表输出用户ID到订单的索引Map第2步输入Map输出活跃用户集合第3步输入Map和用户集合输出金额汇总第4步输入金额汇总输出带币种换算的结果。四个函数没有一个是同构的。为了组合我给每个函数声明了入参、出参、依赖上下文、副作用四个槽位。组合器在运行时自动完成把第1步的结果写入上下文env.orders把第2步的活跃用户集合写入env.activeUsers第3步声明依赖orders与activeUsers运行前自动从上下文取第4步从上下文取金额汇总做币种换算。就这样四个形状各异的函数以描述各自契约、由编排器自动接驳的方式组成了完整链路。运行时只有两步展开链、依次执行代价很小。这个设计真正的价值在于**你不用为了组合去强迫每个函数长一样。**函数各自保持最自然的签名组合逻辑全部收敛到编排器里。改链路时增删一个函数只需改对应配置项不再牵扯其他函数签名。我拿真实项目试过一次重构把原来6个互相嵌套的函数拆成了9个可组合单元主流程代码量从200多行降到40行剩下的全是组装。2.2 歧义不是bug是描述力的上限我见过不少做组合工具的人试图彻底消灭歧义——给每个组合子加极其严格的类型约束让任何不匹配在编译期就报错。愿望是好的但真实业务的歧义恰恰是需求本身的一部分。举一个真实例子。运营系统里有个默认推荐位的功能当用户没有个性化推荐数据时显示规则推荐位当个性化数据存在但为空时显示兜底推荐位当个性化数据存在且有内容时显示个性化推荐。三个分支对应三种不同的数据状态就是典型的按上下文选组合路径。如果用严格的类型系统表达你得为这三种状态分别建模但用上下文感知编排器表达就只是决策节点根据上下文信息选择右侧子组合这一个配置。前者的模型更严谨后者的开发成本低一个量级。关键在于**歧义只是描述层面的不完备不是逻辑上的错误。**编排器要做的不是消除歧义而是把歧义变成显式的决策节点让业务方看得见、改得动。这也是我后来在项目里反复强调的组合的第一性原理**组合的本质不是消除复杂性而是把复杂性从代码的隐式交织中转移到显式配置中。**复杂度的总量不变但显式之后人才能掌控它。3. 参数路由与依赖注入组合链的血管系统这一章要说的是整个方案里最难啃、也回报最大的一块。如果说执行器是组合的骨架那参数路由就是组合的血管系统。3.1 组件的依赖自省机制组合链要优雅不能光靠把函数串起来。真正的瓶颈在于三件事**参数从哪来、结果往哪去、依赖怎么满足。**我把这三件事统一叫参数路由。在传统代码里参数是在调用点直接传递的。函数f(g(x))中g的结果是f的入参明确而直接。可一旦链路拉长、分支变多一个中间结果往往被多个下游函数使用手动传递会变成一场噩梦——你不得不在每一层签名里加参数或者写一堆中间变量。我的方案是在组合上下文中做依赖注入。每个函数显式声明自己需要哪些上下文键读依赖和会写哪些上下文键写依赖。运行前编排器做一次静态推导如果一个函数的读依赖在前序步骤中没有对应的写依赖直接抛出配置错误如果两个并发函数写同一个上下文键在组合定义期就报警如果某个函数的写依赖无人读取提示孤儿结果。这套推导等于给组合链路做了一次定义期体检。它不依赖运行时类型纯粹靠依赖关系图。我在工程里实际遇到过一个同事把userRepo和userCache两个上下文键分别写入下游函数读的是userCache但中间某个函数漏了刷新缓存。静态检查在组合定义期就报出了userCache 的写入方缺失这个问题在原有代码里藏了三个月才发现。3.2 数据流方向约定输入左进右出结果向上冒泡依赖注入解决了参数从哪里来还有一个更隐蔽的问题结果的去向。在传统函数调用中返回值的消费方是确定的——调用它的那个函数。但在编排链路中一个函数的结果可能被三个下游函数使用也可能被组合器自己保留、最终作为整个链路的输出。我在实践中收敛出一套简单的约定避免了绝大部分数据流混乱链路的最终输出必须由某个函数显式声明为output指向上层容器上下文。你不声明组合器不会自动把任何中间结果上浮。中间结果的作用域默认只在当前子链内可见。如果要跨链必须显式把结果写入共享上下文。下游消费下游函数通过上下文键读取上游结果而不是通过记住函数返回值来消费。这套约定的本质是**让数据流方向在组合定义中可见而不是靠阅读函数签名去猜测。**我见到太多组合失败的项目根因不是组合器性能不够而是数据流方向模糊——改一个函数不知道会影响哪些下游加一个参数不知道要从哪里传入。约定清晰之后这些不知道全部变成了查配置就知道。我再用一个例子说明这套约定有多稳。某次重构优惠计算引擎链路有27个节点涉及金额、费率、优惠、封顶、缓存、审计日志六个维度。旧代码是层层嵌套的回调每次改需求都要把整条链在脑子里过一遍。重构后每个节点在配置里声明输入输出键路由完全自动。改优惠逻辑时我只动了调整节点和它的两个下游节点的配置主流程一行没改。这个经历让我确信组合链的优雅不在于节点少而在于节点之间的接缝干净。4. 组合的时间维度异步、并发与执行模型谈完空间上的数据流必须把时间维度补上。函数组合最容易翻车的地方就在时间。前面提过组合子分为立即执行与惰性执行这一章把时间维度彻底补齐。4.1 Promise链路、并发扇出与扇入的组合表达实战项目的组合链路里几乎没有手写过Promise.all式的扇出也没有手动async/await编排。不是这些工具不好而是组合上下文里已经有了更统一的抽象。具体来说我在组合上下文中内置了三种执行模式串行默认执行每个函数等前一个完成。扇出一个函数的结果同时送入多个下游函数并行执行对应手写Promise.all([...])的场景。扇入多个并行函数的输出汇聚成一个结果对应等待所有分支完成再做汇总的场景。条件分叉决策节点根据上下文值选择左侧或右侧子链执行。执行模式的声明不依赖函数内部而是配置在组合子的连边上。这意味着同样的函数单元可以挂在串行边上也可以挂在扇出边上函数本身对执行模式一无所知组合器在运行时根据边配置调度。我用一个典型场景说明订单创建后需要同时做三件事——发通知、写审计、清缓存。这三件事直接串行执行会很慢手写Promise.all又要维护三份状态。用组合上下文表达主链第1步创建订单写入上下文env.order。第2步扇出把env.order同时送入发通知写审计清缓存三个子函数。第3步扇入等三个子函数都完成统一记录完成状态。整个过程中每个子函数依然只关心自己的入参出参完全不感知自己在并行执行。我实测过原来手写Promise.all的那段逻辑大约60行用组合上下文表达后节点代码总量不变但主流程的编排部分从60行降到5行配置。可读性提升是实打实的。4.2 执行模型设计串行/并行边界由定义期授权运行时只做转发说到执行模型有一个容易被忽略的原则并发不该是函数内部偷偷做出来的而应该是组合定义期的显式授权。为什么因为并发一旦藏在函数内部组合器就失去了对整条链路的全局视野。它不知道某个函数内部开了几个并行任务也不知道哪些并发可以优化哪些必须严格串行。这种局部并发往往引发两类问题一是资源竞争多个内部并发任务同时操作同一上下文二是性能假象并行任务太多反而拖垮系统。我的约定是**函数内部禁止偷偷并发所有并发行为必须在组合子边配置上显式声明。**某个函数想并发就声明为扇出或扇入的节点。这样编排器在组合定义期就能画出完整的执行拓扑运行期只是按图转发结果。这个原则在真实项目中帮过大忙。某次性能排查某个服务在高峰期的响应时间极不稳定。用执行拓扑图一查问题不在业务函数而在某个函数内部偷偷用了并发池高峰期把连接池打满了。把它改为组合配置级别的扇出后拓扑图清晰地显示并发上限服务响应时间恢复稳定。这再次印证组合的优雅不是靠函数自我修养而是靠定义期的结构约束。5. 用户价值场景从写函数到搭积木理论说了这么多如果落不到真实价值上全是空谈。这一章我用实际场景展示函数组合的极致实践最终给使用者带去了什么改变。5.1 组件复用从复制粘贴变成配置引用这个转变是我最想让读者体感的差异。传统写法里复用一段逻辑一般就是复制一份代码、改几个参数、贴到另一个地方。短链路还好长链路复用几乎必然走神——你复制了A版本的参数忘了B版本的异常处理上线后才发现。组合上下文让复用变成了配置引用。一个函数写好它只是积木的一块。两个项目要用同一个处理逻辑不需要复制代码只需要在两份组合配置里引用同一个函数ID。逻辑本身的修改只发生在一处所有引用它的组合自动生效。我经历过一次很有说服力的场景某个折扣计算函数原来在三个业务链路中被以不同方式调用。第一次是直接调用第二次是加上缓存第三次是套了一个重试。重构为组合配置后三个链路分别引用同一个函数ID差异只体现在各自组合的边配置上——一个直连、一个加缓存节点、一个加重试节点。那个函数本身一行没改。后来规则变更我只改了这个函数一处三个链路同时生效。复用从复制粘贴的物理复制变成了引用装配的逻辑组合这是质的区别。5.2 主流程可读性提升领域语义优先于调用过程函数组合真正高级的地方在于主流程终于可以说人话了。传统代码主流程是这样先做A然后调用B的返回值做C如果C成功再做D和E最后汇总成F。这段流程如果写在代码里阅读者需要逐个看函数签名、看返回值、看调用关系才能还原业务本来面目。用组合上下文配置表达同样流程主流程长成这样校验输入计算基础价格按会员等级应用折扣如果总额大于阈值追加满减组装报价单。我可以负责任地说当我把这段配置拿给业务同事看的时候对方不需要懂代码就能指出问题满减逻辑现在写在了折扣之后但实际应该是先满减再折扣。这是一个在旧代码里藏了两年的业务bug在组合配置上一眼暴露。**可读性不只是审美问题它是让业务语义浮出水面的工具。**组合的优雅最终落在人能不能看懂自己在组合什么上。5.3 调试与观测组合链路的可追踪性是最大的增量收益最后一个价值可能是最被低估的调试体验的改变。单函数调试很直接——打断点、看变量。但组合链一旦变长断点调试几乎不可用你不知道当前执行到哪一步、哪一步写入了哪个上下文键、哪一步丢弃了哪个结果。传统方案只能靠日志一行行猜。我的组合上下文内置了一个针对性的观测能力每个函数执行时自动记录输入快照、输出快照、耗时、写入的上下文键。这条链路在调试时能以时间线形式完整回放每一步的输入输出都一目了然。有个印象很深的排查经历某次线上问题某个订单算出来的金额少了10块。旧代码链路长排查要一个个断点去试。用组合上下文的时间线我直接看到第4个节点满减计算的输入快照里有一笔9.9元的优惠券被计入了满减基础额。这是一个典型的上下文污染问题——上游把优惠券信息写入了不该写的键下游错误读取。时间线一眼定位5分钟就修完了。观测能力让组合链路的复杂度从不可控变成可审计这个增量收益在长链路里是决定性的。6. 边界、局限与务实建议任何技术方案都有边界。函数组合的极致实践也一样有些场景它闪耀有些场景它不该硬上。这一章说清楚。6.1 过度组合的信号什么时候该收手组合是有成本的。抽象层每多一层配置就多一层排错就要多穿透一层。我见过很多团队从觉得组合很优雅滑向为了组合而组合最后维护成本爆炸。这里给出我的判断信号一个组合配置超过30个节点且仍在持续增加就该考虑拆分或收敛组合配置里频繁出现条件选择整条链的节点说明你在用组合器写状态机可能应该用专门的状态机工具团队新人看完配置后无法在三分钟内说出主流程做了什么说明配置的可读性已经败给了复杂度。我不反对在复杂场景继续用组合但**组合的复杂度必须始终以可读性为上限。**一旦配置本身比原来的命令式代码更难读懂组合就失去了意义。这是我用几次痛苦重构换来的教训。6.2 组合与测试领域逻辑照常单测组合器只测装配与路由组合工具的引入让不少团队担心一个事测试怎么办原来每个函数单独测现在整个链路在组合器里跑单测还怎么写我的实践里测试策略其实很清晰领域函数保持纯函数式单测每个函数独立测试入参、出参、边界条件跟组合器毫无关系。组合配置单独测装配正确性用一个假的上下文跑一遍组合定义断言每个节点的输入输出键是否按预期连接、依赖是否满足、执行模式是否符合预期。关键链路做端到端冒烟一条主链路从入口到出口用真实或模拟数据完整跑一遍。这三个层次互不干扰组合器本身几乎没有需要测试的魔法因为它的逻辑就只是读配置、转发数据。魔法都在配置的依赖关系里而依赖关系由静态检查在定义期兜底。以我的经验组合代码的bug率远远低于传统调用代码因为出错的地方从运行时逻辑前移到了配置期检查。6.3 务实路线图从一行compose到组合上下文的渐进路径最后给想实践的朋友一条不吓人的路径。不要一步跳到组合上下文这种重方案实践下来步子太大容易扯到蛋。我的建议是第1步写一个纯函数组合子先习惯compose/pipe的心智模型。很多收益从这个阶段就开始了。第2步给组合子补上异常上下文与日志能力。链路长起来后这是刚需。第3步引入组合上下文先只做依赖注入不碰并发编排。这一步会立刻解决参数地狱。第4步加入扇出/扇入与条件分叉的执行模式。这时候才算完整拥抱组合式编排。第5步把组合定义收拢到配置层团队开始把组合当成一门可以被审查的语言。每一步都有独立收益不必等全套方案落地才开始用。我在自己可控的项目里就是一步步走到第5步的中间没有任何一步是浪费的。行文至此我梳理了函数组合从单行compose到组合上下文的全景从基本原理到编排器关键设计从参数路由到时间维度从用户价值到务实边界。照惯例最后不做总结只留一句我常跟团队说的话让每个函数只描述是什么让组合去决定怎么跑让上下文决定数据去哪剩下的交给配置去表达。希望对正在摸索组合式设计的朋友有一点点实在的启发。