函数流水线实战：用pipe和纯函数重构复杂业务逻辑-代码聚汇网

函数流水线实战：用pipe和纯函数重构复杂业务逻辑

不靠谱的糖饼·2026-09-05·阅读 80 GEO检测（免费）

函数流水线pipecompose

|难度：普通|阅读约 37 分钟

1. 从一段“能跑但不敢动”的代码说起：为什么要拆函数流水线

先抛个问题：你有没有遇到过这样一种函数——它从接口拿数据，然后清洗、过滤、排序、分组、再拼上展示字段，五十行起步，夹着三个forEach和两个reduce，缩进层层叠叠像千层蛋糕？功能是好的，跑起来也没毛病，但过两周需求改了，要加一个字段，你打开那个函数，发现自己完全不想动它，因为一动就怕碰坏别的地方。

我在不少项目里见过这种代码。它的本质问题只有一个：一个函数里塞了太多条流水线工序。数据从入口进来之后，经历了什么、在哪一步被改变了形状、哪一步最耗时、哪一步可能抛异常，全凭肉眼去读逻辑，而不是凭结构去推断。维护这种代码，靠的是胆量和记忆力，而不是可预测性。

函数流水线（Function Pipeline）想解决的问题，就是把这个过程倒过来。数据不是被塞进一个大黑盒里，而是被拆成一段一段独立的工序，前一段的输出就是后一段的输入，数据像在一条真实的流水线上往前走。每一段工序都是一个纯函数——输入确定，输出就确定，不修改外部状态，不把脏数据往下一步传。

这种思路不算玄学，它其实就是函数式编程里“组合”思想在工程上的落地。JS作为一门多范式语言，完全支持这么写，而且现在原生API也越来越配合这种写法（数组的map/filter/reduce本身就是流水线的雏形）。但真正把“用map filter顺手处理数组”升级成“用流水线组织整个业务逻辑”，中间还差着一层设计上的认知。

这篇文章我从头拆一遍函数流水线的原理和实现，不讲大而空的概念，直接落到代码上。上篇先讲核心：流水线是什么、如何用函数组合子实现、以及如何用流水线重构一段真实业务逻辑。下篇留给异步流水线、错误处理和类型约束这些进阶话题。适合已经写过一段时间JS、对函数式编程有点兴趣但还没真正在业务中用起来的开发者。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 流水线的本质：数据形态的逐步收敛

想理解函数流水线，建议先忘掉“函数”这个词，想象一条真实的工厂产线。原料从传送带一头进去，第一道工序把原料切成型，第二道工序打磨边角，第三道工序喷漆，第四道工序质检。每道工序只关心自己接到的半成品长什么样，也只负责输出自己这一环节的结果。没有任何一道工序需要知道整条产线一共有几道工序，更不需要知道前一道工序内部怎么实现。

函数流水线就是这个模型的直接映射。

2.1 每一段工序都是一个纯函数

流水线的第一原则是：每一段都是纯函数。所谓纯，两个条件：

同样的输入，永远得到同样的输出。
执行过程不产生可观察的外部副作用（不修改传入的对象、不写全局变量、不打日志、不发送请求）。

这不是为了追求理论上的洁癖。工程上，纯函数最大的价值是可替换性和可测试性。流水线上一段坏了，把它单独拎出来传给一组固定输入，立刻就能定位问题。而不纯的函数，排查起来往往要靠断点、日志、猜想，效率差一大截。

比如下面这个不算流水线、看起来也不复杂的函数：

javascript复制function processOrders(orders) {
  const valid = [];
  for (const order of orders) {
    if (order.amount > 0) {
      valid.push(order);
    }
  }
  valid.sort((a, b) => b.amount - a.amount);
  for (const order of valid) {
    order.total = order.amount * (1 - (order.discount || 0));
    order.level = order.total > 1000 ? 'VIP' : 'NORMAL';
  }
  return valid;
}

问题很明显：先筛选、再排序、再计算、再分级，全混在一个函数体里。而且它在原对象上加了total和level字段，等于改动了输入数据。调用方如果后面还要用原始amount，一不小心就会拿到脏数据。

用流水线的思路看这段逻辑，工序应该拆成四个：

过滤出有效订单。
按金额倒序排序。
计算每单实付金额。
根据实付金额打等级标签。

每个工序只做一件事，并且不修改原数组和原对象。

2.2 数据形状的逐步变换

流水线的另一个关键概念是：数据在流经每道工序时，形态（shape）可能发生变化。从数组变成新数组，从数组变成对象，从对象变成字符串，都行。这恰恰是它比面向对象链式调用更灵活的地方。

链式调用其实也是一种有限意义上的流水线，比如数组的map、filter链：

javascript复制orders
  .filter(o => o.amount > 0)
  .sort((a, b) => b.amount - a.amount)
  .map(o => o.amount * (1 - (o.discount || 0)));

但链式调用的局限在于：数据只能在同一个类型（比如数组）上操作，中间步骤如果想改变数据类型，链就断了。而函数流水线没有这个限制。前一步输出字符串，后一步就能按字符串处理；前一步输出对象，后一步就能把对象塞进新的数据类型里。每个函数都是独立的，连接它们的方式就是传参。

所以总结一句话：**函数流水线就是一组按顺序执行、参数单向传递、且每步都能独立替换和测试的纯函数集合。**这个定义很简单，但把它真正做到位，靠的是组合工具的设计。

3. 组合子的选择：pipe还是compose，区别不只是方向

有了纯函数和拆分工序的意识后，下一个问题是怎么把它们串起来。最朴素的写法是手动嵌套，或者写一堆中间变量：

javascript复制const step1Result = filterValid(orders);
const step2Result = sortByAmount(step1Result);
const step3Result = calcTotal(step2Result);
const result = markLevel(step3Result);

这当然也算流水线，但工程上不够优雅——变量名要费脑筋，每一步的临时值都暴露在当前作用域里，步骤一多，又回到了“千层蛋糕”式的阅读负担。

真正要解决的是函数组合问题。常见方案有两个：pipe（管道）和compose（组合）。

3.1 方向之争：从左到右还是从右到左

先上代码：

javascript复制// pipe：数据从左往右流
function pipe(...fns) {
  return (input) => fns.reduce((acc, fn) => fn(acc), input);
}

// compose：数据从右往左流
function compose(...fns) {
  return (input) => fns.reduceRight((acc, fn) => fn(acc), input);
}

pipe(f, g, h)(x) 等价于 h(g(f(x)))，先执行f，再g，再h。
compose(f, g, h)(x) 等价于 f(g(h(x)))，先执行h，再g，再f。

为什么会有两种方向？因为compose是数学里函数复合 f∘g 的直译，读的时候从右往左，符合“先把数据交给最右边的函数，得出结果再交给左边一个”的语义。而pipe把顺序翻转过来，完全按照人脑从左到右的阅读习惯，先写的先执行。

就工程实践而言，我更推荐pipe。原因很直接：人天然是沿着执行顺序读代码的。写业务逻辑的时候说“先过滤、再排序、再计算”，对应的就是从左到右写函数名。compose的反向阅读在纯函数式学术讨论里有它的优雅性，但业务代码里执行顺序被打乱，阅读成本反而更高。

3.2 一元函数的约束

pipe和compose都要求一个核心前提：组合链里的每个函数都得是接收一个参数的一元函数。

这一点很关键，也最容易在实际项目里踩坑。比如：

javascript复制const unfiltered = [1, 2, 3, 4].map(power); // power需要指数参数，能直接pipe吗？

不能，因为你没法在pipe链里给power传第二个参数。解决方案是先用柯里化（currying）或者高阶函数把多参数函数“包装”成单参数版本：

javascript复制const power = (exp) => (base) => base ** exp;

这样power(2)返回一个新函数，这个新函数只接收一个参数，可以放进pipe链里。

真实场景中经常用一个封装好的map工具函数，把数组的map变成可组合的一元函数：

javascript复制const map = (fn) => (arr) => arr.map(fn);
const filter = (fn) => (arr) => arr.filter(fn);

这样filter(o => o.amount > 0)就是一个一元函数（接收数组），可以顺利进入pipe链。

3.3 用什么实现方式：reduce其实就够了

有人一听到实现pipe，第一反应是用递归，或者用中间数组展开。其实最优雅的实现就是上面那两行——一个reduce或reduceRight，不需要依赖任何库。

不过要注意一点：reduce初值的问题。上面的pipe实现里，返回的函数接收input后，直接用input作为reduce的初始值，第一个函数立即处理input，返回的结果作为下一次遍历的acc。这种实现没有任何多余的中间数组，时间复杂度就是O(n)。

也有另一种变体，先把输入存起来，最终调用时才真正执行，也就是“惰性展开”：

javascript复制const pipe = (...fns) => (input) =>
  fns.reduce((result, fn) => fn(result), input);

这个和上面其实是一样的——reduce的执行本来就在返回的函数被调用时才发生，所以天然是惰性的。

对于现在大多数JS运行环境，这种量级的reduce不会有任何性能问题。真正要注意的是不要在一个pipe链里塞几百个函数，那属于设计问题，不是实现问题。

4. 从工具函数到业务重构：一个实际案例的完整拆解

光讲概念容易飘，下面拿一个具体业务场景完整走一遍流水线重构。这个例子我特意选了一个现实中相当普遍的形态：从接口拿到订单原始数据，然后做一系列处理，最后输出前端表格需要的结构。

4.1 原始代码的问题定位

假设接口返回的订单数据长这样：

javascript复制const rawOrders = [
  { id: 1, customer: 'Alice', items: ['A', 'B'], amount: 500, discount: 0.1, status: 'paid', createdAt: '2024-05-01' },
  { id: 2, customer: 'Bob', items: ['C'], amount: 1500, discount: 0, status: 'pending', createdAt: '2024-05-03' },
  { id: 3, customer: 'Carol', items: ['A', 'C', 'D'], amount: 300, discount: 0.2, status: 'paid', createdAt: '2024-04-28' },
  { id: 4, customer: 'Dave', items: ['B'], amount: 800, discount: 0, status: 'paid', createdAt: '2024-05-02' },
];

后端不做太多处理，前端拿到后需要：

只保留已支付订单。
按创建时间从早到晚排序。
计算每单实付金额（amount * (1 - discount)）。
判断订单规模（实付>600为“大单”，否则“普通单”）。
组装成前端表格需要的行数据结构。

传统写法通常长这样：

javascript复制function buildTableData(rawOrders) {
  const paidOrders = rawOrders.filter(o => o.status === 'paid');
  paidOrders.sort((a, b) => new Date(a.createdAt) - new Date(b.createdAt));
  const result = [];
  for (const order of paidOrders) {
    const total = order.amount * (1 - order.discount);
    result.push({
      id: order.id,
      customer: order.customer,
      total: Math.round(total),
      scale: total > 600 ? 'LARGE' : 'NORMAL'
    });
  }
  return result;
}

这个函数能跑，但有几个问题值得注意。

第一，sort直接修改了paidOrders，而paidOrders又是rawOrders.filter的产物，虽然此时的paidOrders是新数组，排序不会影响rawOrders本身，但这种写法的意图不够明显——看着像在“原地整理数据”，容易让人误会会改动原数组。

第二，筛选、排序、计算、组装全部在一个函数体内逐行展开，函数从上到下的每一行“步骤感”太弱，更像是在描述What而不是How。

4.2 用pipe重构，过程和结果都变清晰

先把每个步骤抽成独立函数：

javascript复制const filterPaid = (orders) => orders.filter(o => o.status === 'paid');

const sortByCreatedAt = (orders) =>
  [...orders].sort((a, b) => new Date(a.createdAt) - new Date(b.createdAt));

const calcTotal = (order) => ({
  ...order,
  total: Math.round(order.amount * (1 - (order.discount || 0)))
});

const markScale = (order) => ({
  ...order,
  scale: order.total > 600 ? 'LARGE' : 'NORMAL'
});

const toTableRow = ({ id, customer, total, scale }) => ({ id, customer, total, scale });

然后组合起来：

javascript复制const buildTableData = pipe(
  filterPaid,
  sortByCreatedAt,
  (orders) => orders.map(calcTotal),
  (orders) => orders.map(markScale),
  (orders) => orders.map(toTableRow)
);

const tableData = buildTableData(rawOrders);

对比原始函数，这个pipe版的优势一眼就能看出来：**每一步做什么，扫一眼函数名就够了。**filterPaid负责筛选，sortByCreatedAt负责排序，后续三个map各自负责一个字段的计算和组装。

这里的map要包裹成(orders) => orders.map(xxx)，是因为我把calcTotal、markScale、toTableRow定义成元素级函数（接收订单对象，返回新订单对象），要放在数组上操作就得outside-in包一层。如果介意这层包装，可以把它们直接定义为数组级工序：

javascript复制const calcAllTotals = (orders) => orders.map((order) => ({
  ...order,
  total: Math.round(order.amount * (1 - (order.discount || 0)))
}));

两种风格各有优劣。元素级函数更贴近“每个对象自己变漂亮”的直觉，数组级函数则能少写一层嵌套。我的习惯是：如果这个工序面向的是集合变换，直接写数组级函数；如果它是通用的数据加工规则，写成元素级函数，将来也方便在非数组场景复用。

4.3 重构过程中意外暴露的三个隐藏bug

这套重构在我真实项目里做完之后，立刻发现了三处原来没注意到的问题。

第一个问题：rawOrders里有几条记录的discount字段是null，原始代码里order.amount * (1 - order.discount)算出来的结果是NaN。因为null乘以数字确实是0，但问题是1 - null等于1，这行还正常；但有的记录discount是字符串"0.1"，1 - "0.1"在JS里会得到0.9，但"0.1"是字符串时，order.amount * (1 - order.discount)没问题，可如果discount是字符串"abc"，结果就废了。保险起见统一做一次安全处理：1 - (order.discount || 0)，并且用Number()包一层。这属于后端数据不规范的典型问题。

第二个问题：原始代码用了paidOrders.sort(...)，它直接在filter生成的新数组上排序，看起来没污染rawOrders，但如果哪天改动导出了paidOrders供别的逻辑用，数据就被悄悄重排了。重构后sortByCreatedAt显式做了[...orders].sort，切断了任何潜在的外部引用影响。

第三个问题：原来没有对total做四舍五入，生成的表格数据可能带一长串小数。表格单元格看着倒无所谓，但后续如果拿这个total去做视觉分层或者二次计算，问题就来了。重构时在calcTotal里统一用Math.round做了处理，顺带让scale判断也有了明确的口径。

这段经验想说一个事：流水线重构的价值不只是代码变漂亮，更是在拆分的过程中逼着你审视每一步的数据边界和异常情况。 工序拆得越细，流经每道工序的数据形态就越明确，潜在问题也越容易暴露。

4.4 断点调试在流水线中的实践方式

有人会担心：函数拆细了、组合起来了，调试是不是变难了？

这个问题得分两面看。定位到具体某一步当然比大函数的全局断点要容易——单测和单独执行就能覆盖。但如果你想看数据流经每一步之后的中间形态，确实需要点技巧。

一个很实用的做法是在任意两个函数之间插入一个透视点：

javascript复制const trace = (label) => (value) => {
  console.log(label, value);
  return value;
};

const buildTableData = pipe(
  filterPaid,
  trace('after filter'),
  sortByCreatedAt,
  trace('after sort'),
  (orders) => orders.map(calcTotal),
  trace('after calc'),
  (orders) => orders.map(markScale),
  (orders) => orders.map(toTableRow)
);

trace返回一个恒等函数，输入什么原样返回什么，只是多打了一条日志。想移除调试信息就把这些trace从pipe里摘掉，不用改动其他代码。团队里如果有人接手，看到trace留下的痕迹也能快速理解数据流转过程。比断点一个个跳过要省事得多。

5. 实现一个可扩展的pipe：非破坏性、错误处理与必要时的追加操作

前面实现的pipe是极简版，足够应付不少业务场景。但真实项目里，光有极简版还不够，有几个实际问题必须先想清楚，否则用到后面会卡住。

5.1 非破坏性设计为什么重要

我在5.2和5.3里强调的“不修改原对象”，放到pipe这个大链条里也一样成立。pipe自己不应该修改传入的初始值，也不应该修改任何一个中间步骤产生的值。因为函数组合的复用场景太多了：同一条pipe可以被不同数据源调用，如果某一步内部悄悄改了输入的某个对象，下一次调用时同样的对象传进来，结果就不可预测了。

所以实现pipe的时候，我倾向于给传入的函数做一个轻量的执行包裹：

javascript复制function pipe(...fns) {
  return function piped(input) {
    return fns.reduce((acc, fn) => fn(acc), input);
  };
}

这个实现本身就是非破坏性的——它只是把input传给第一个函数，然后把返回值传给第二个函数，从头到尾没有对input做任何其他操作。破坏性来自个别函数内部，比如原本的sortByCreatedAt如果直接sort了传入的数组，pipe整体就会产生副作用。解决办法我上面给了：每个数组类工序拿到数组后先展开再排序（[...orders].sort），保证不影响上游。

5.2 中间结果返回处理：安全和可选项

其实还有一个很容易被忽略的问题：如果某个工序返回undefined，管道会直接崩。这在调试初期特别常见——想在某一步过滤掉一些数据，结果把数组条件写错了，filter返回的是undefined而不是数组。

一个实用的防御方案是在pipe内部检查每个中间结果的类型，如果发现try-catch能兜住的错误，就用try-catch接住并抛出更清晰的错误信息：

javascript复制function pipe(...fns) {
  return function piped(input) {
    return fns.reduce((acc, fn) => {
      try {
        return fn(acc);
      } catch (err) {
        const fnName = fn.name || 'anonymous';
        throw new Error(`[pipe:${fnName}] ${err.message}`);
      }
    }, input);
  };
}

这么做有个明显的好处：出错的时候，错误信息里会带出是哪道工序挂的，而不是只给你一个底层堆栈。对排查问题非常省时间。

5.3 惰性计算与真实场景的取舍

前面提到pipe返回的函数“调用时才执行”，其实这已经是标准的惰性。但还有一种“惰性构造”的思路：如果一条pipe里有几十个fns，可以在管道构造时做一次浅拷贝，避免数组引用被外部篡改。

javascript复制function pipe(...fns) {
  const pipeline = [...fns];
  return function piped(input) {
    return pipeline.reduce((acc, fn) => fn(acc), input);
  };
}

这种拷贝开销极小，换来的是持有这个管道的代码无法动态增删步骤（除非再暴露接口）。对团队协作来说，管道一旦创建就是稳定的，反而更好维护。如果想支持动态追加，可以返回一个带append方法的对象，但这会让返回值不再是一个纯函数。我的建议是：业务代码里用纯函数版就够了，需要动态扩展逻辑的时候，直接用数组去管理工序，别在pipe对象上造新概念。

6. 从函数式思维反哺模块设计：流水线对代码组织方式的影响

拆到这一步，细心的读者会发现，函数流水线不只是个技术工具，它在倒逼你重新思考“代码应该怎么组织”。

6.1 把“步骤”变成一等公民

传统命令式代码里，“步骤”是散落在函数体内的语句，靠缩进和空行勉强分隔。流水线把“步骤”提升为独立函数——每个步骤都被命名、可以被单独测试、可以被复用。这种思维方式一旦建立，对模块划分会产生连锁影响：你会发现很多大模块本质上就是一条更粗粒度的管线，管线上的每个节点都可以发展成一个独立的文件或模块。

比如订单处理这条业务线，可以拆成：

code复制inputSchema（校验）
normalize（规范化）
filter（过滤）
enrich（补充信息）
outputSchema（格式化输出）

每个模块只负责一个环节。新需求来了，不是在原来的模块里堆逻辑，而是找对管道位置插一个新模块进去。这很像中间件机制（express的中间件、redux的中间件都是同一思想的产物）。理解流水线，对理解这些框架设计也有帮助。

6.2 流水线的极限：什么时候不该用pipe

任何工具都有边界。函数流水线不适合的场景也不少，得直言不讳。

第一种：强顺序依赖且需要频繁分支的场景。比如支付流程，状态机式的跳转比管线更清晰。管线适合“一笔数据从头流到尾变一个样”，状态机适合“根据当前状态决定下一步去哪”。硬把状态流转塞进pipe，函数之间的条件判断会堆满代码，适得其反。

第二种：大量异步操作且需要并发控制。pipe天然是串行的，一步等一步。如果你有五个并发请求要发，之后才统一汇合处理，那更适合Promise.all组合，而不是硬塞pipe。异步流水线确实是可行的，我会在下篇详细展开，但它绝不是所有异步场景的银弹。

第三种：团队里大部分人编程范式还没转过弯来的时候，强行在核心业务里铺开几十条pipe，代码会很飘逸但没人接得住。这时候可以先从核心工具函数开始用pipe，让其他成员逐渐适应这种写法。

6.3 命名是最重要的一道工序

最后说个实操中体会最深的事：流水线里的每个函数名，其实就是这条管线的“文档”。函数名叫filterPaid，读的人不关心里面是一个filter还是三个嵌套循环，只关心语义。所以在拆流水线时，给每个工序起名字的时间，不应该少于拆工序本身的时间。

我倾向用“动词+名词”或“动名词开头”的命名方式，一眼能看出这个工序拿什么、做什么、出什么。比如：

normalizeOrders
mergeCustomerInfo
calculateGrossMargin
convertToCSVRow

而不是什么doAllThings、util1这种看了等于没看的名字。函数组合的透明性，很大程度是建立在命名清晰之上的。命名糊弄了，pipe链再好也白搭。

7. 写在最后的实践体会

函数流水线这篇文章写到这里，上篇的核心内容差不多了。我把自己几年下来实际用它重构老代码的体会浓缩成三条，供参考。

第一条，从最小的场景切进去，不要一次性重构整座山。 挑一个你最头疼的大函数，把里面的步骤拆成五个独立函数，再套上pipe接起来，先感受一下数据流转清晰带来的反馈。有了正反馈，后面自然就有动力铺开。

第二条，pipe工具本身很简单，真正难的是拆解。 拆解的过程，其实是在逼你回答：这道工序的输入到底是什么、输出到底是什么、它会不会对外部产生副作用。这三个问题想清楚，代码质量差不到哪里去。

第三条，不要为了用而用。 三条五条工序的函数，直接老实写也不丢人。流水线带来收益的前提是工序足够多、逻辑足够复杂，复合收益才会明显。强行把小逻辑拆成十段，反而增加阅读跳转成本。

下篇我会接着讲异步流水线——如何处理Promise串行、并发、错误中断和失败重试，以及怎么在TypeScript里给pipe加上类型推导。这些问题在实际项目中几乎都会遇到，到时候拆开逐个解。