前阵子有个朋友问我n8n里循环处理完一批数据想把它们汇总成一张表或者一段JSON怎么老是要写Function节点我说你试试Aggregate节点他一试就回不来了说以前白写了那么多代码。其实n8n里不少刚接触的人都会有这个困扰——处理单条数据顺手一旦碰到多条变一条多组分一组的需求就开始用代码硬实现。这恰好就是Aggregate节点的主场。这篇我就把Aggregate节点的用法、参数背后的逻辑、以及我在实际项目里踩过的坑一次讲清楚适合刚入门n8n不久、或者已经在跑工作流但总觉得聚合这一步绕远路的朋友。你可能会先注意到界面上的Summarize、Merge、Aggregate这几个节点乍一看都是跟数据合并沾边的。后面我会专门讲三者的分工边界。先聚焦Aggregate——它在n8n的定位很简单把工作流里某一刻承载的多条数据按你指定的方式合并成一条或一个数组。听起来像废话但这恰恰是很多自动化流程从能跑变得好用的关键拐点。聚合数据看起来是个小功能实际牵涉到Item结构、循环范围、引用方式等一系列观念理解了它你读别人的工作流也会快很多。1. 为什么说Aggregate是化整为零的反向操作——先看它的核心价值1.1 一条数据是一条Item一堆数据怎么变成一块数据n8n里每个节点往下传的是一组数据每条数据在官方文档里叫一个item。比如HTTP Request请求一个列表接口返回100条记录那下一个节点收到的就是100个item再比如Loop Over Items节点循环执行了10次后面接的节点每次收到1个item但循环结束后如果你想把10次的结果汇总成一个大数组这就是Aggregate的活。我打个比方你就能理解普通节点像流水线上的传送带一个个零件挨个往下送Aggregate角色更像一个集装工把传送带上的零件码进同一个箱子里再往下传。它的核心价值在于改变数据的颗粒度——从多粒度变单粒度或者说是把分散的数据打包方便后续一次性写入数据库、生成报表、推送给Webhook。我第一次特别明显地感受到它的存在是在做电商订单对账的流程里。订单查询接口是按店铺维度分批返回的每批100条后面我要把所有店铺的数据汇总写进一张汇总表如果不用Aggregate就得在循环里一条条upsert请求次数多、API压力大、速度还慢。把循环里的数据聚集一次变成一个大数组然后一次性批量写入效率根本不在一个量级上。1.2 聚合的产物是数组还是对象决定了后面好不好接Aggregate节点最关键的一个设置是聚合方式。它有两种输出形态把所有item聚合成一个数组Aggregate All或者按某个字段分组每组输出一个数组Aggregate Individual。这个选择直接决定下游节点怎么消费这批数据。举一个最常见的场景你从数据库里查了三个不同维度的统计数据得到三条item希望合并成一条包含三个字段的item。这时候你用Aggregate All且勾选合并到单个item模式输出就是一条item字段是数组如果你不勾选输出是一个数组数组里三个元素对应原来三条数据。这两种产物长得差不多但结构差别很大下游用表达式引用时写法完全不同。我见过有人在这个设置上卡了一晚上本质是没搞明白数组里套item和一个item里套数组的区别。所以建议你在动手配置前先想清楚一个问题下游节点期待的是什么数据库字段需要数组还是需要JSON字符串通知消息里是要逐个列出还是用逗号拼接把这个想明白Aggregate配置基本不会错。2. 参数面板拆解三个关键选项的真实含义与搭配方式2.1 聚合方式全部聚合与分组聚合打开Aggregate节点第一个要选的就是聚合方式Aggregation就两个选项Aggregate All和Aggregate Individual。Aggregate All最简单它把所有输入item合并成一个数组。典型用法是循环内部分页请求把每一页的多条记录全部收敛到一个大数组里。整个过程非常直接不需要额外条件。Aggregate Individual则是按字段值相同来分组。它给了你一个字段名列表比如按userId分组那么所有userId相同的item就归到一个数组中不同的用户各成一个数组。这个模式下一个节点输出可能会产生多个数组每个数组是同一组的item。这个功能适合做分组汇总的前置步骤先分组后面再接Summarize去聚合计算或者直接按组去批量处理。我平时用得最多的是Aggregate All只有在需要按用户归类订单、按日期归类日志这类场景时用Individual。它本质上是省掉了一个自己写分组逻辑的步骤。2.2 字段合并把所有字段都收进来还是挑几个第二个重要设置是Fields也就是你最终想保留哪些字段。默认情况是保留全部字段聚合时所有item放到数组里时字段自然是都带着。不过实际项目里数据源头经常有一堆用不到的字段比如接口返回的_id、__v、status_code之类的调试信息聚合后全都留着既占地方又显得乱。你可以在Fields里指定只保留orderId、amount、createdAt这几个关键字段数组里每个元素就只含这几个字段。后面的节点不管是转JSON还是写数据库结构都干净很多。我一般习惯下游要什么字段就在聚合前用Edit FieldsSet节点先裁剪一下再到Aggregate里去聚合。这样做还有一个附带好处排查问题的时候一眼就能看出数据里有什么不会被无关字段干扰。还有一个要留意的点是勾选了合并到单个itemToggle Binary / Combine into a single item之后各个字段会成为数组字段这个时候各item如果字段名不一样n8n会怎么处理呢默认情况下它会自动补齐字段比如一个item有name另一个item有email合并到单item后这个item会同时有name数组和email数组哪个item缺某个字段对应位置就是空值数组长度保持一致。这算是n8n做得比较聪明的地方但它同样也会带来一个坑如果两个item的字段语义相同但叫法不同比如一个叫date、一个叫time那会生成两个数组而不是合并到一起。写数据解析时稍不留神就把这俩混了所以上游字段命名保持一致非常重要。2.3 分组聚合时按什么分的思考逻辑如果你选择了Aggregate Individual面板会多出一个字段让你指定按哪些字段分组。这一块我建议你按这个顺序来判断分组字段必须稳定值不能是随机变化的比如时间戳精确到毫秒分组就意义了分组级别要合适你要是按item_id分组基本等于没分组每个组就一条记录按order_status分组又可能分的太粗下游还要再拆。我接手过一个对账项目里面需要把多笔支付流水按支付渠道分组再统计每个渠道的金额。当时就把channel当分组字段聚合后再用Summarize对amount求和。这样两个节点一配合几行配置就完成了原本要在代码里写十几行的分组统计逻辑。3. 从循环分页到批量入库——三个真实场景的完整配置过程3.1 场景一循环内累加数据循环结束后一次性汇总这是Aggregate最典型的使用场景。有个爬虫需求是这样的目标数据源限制只能按日期逐天查询我需要循环从1号跑到30号每天返回当天的订单列表最后把30天的结果汇总成一个完整列表统一落库。如果不用Aggregate比较笨的办法是在循环里每跑一次就写一次数据库API连接反复建立、事务多次提交又慢又卡。合理做法是外层用一个Loop Over Items节点准备好的日期数组作为循环源循环内部用HTTP Request请求每天的订单数据请求结果接一个Set节点保留需要的字段在循环体内或者循环外部接一个Aggregate节点把每次循环的数据聚合起来。这里有个位置细节值得说清楚Aggregate节点放在循环体内部和外部行为是不同。如果你放在循环体内部并且开启了合并到单个item那每循环一次之前聚合的结果会被新的item一起再聚合一次形成一个逐步膨胀的大数组循环30次后数组里会有30批数据叠在一起。有效但每次循环都在重新组合前面所有结果是个O(n²)的操作数据量大时会明显变慢。更推荐的做法是把Aggregate放在循环之后和Loop Over Items节点同级用loop的done连线或者在Loop节点内部数据流结束位置接出。因为循环结束之后那批数据已经积累在n8n的流程data里了这时候聚合是一次性的效率高思路也清晰。我在写工作流时习惯把聚合这一步放在循环外做这是很多n8n教程不会明说的小细节。3.2 场景二分页接口的数据合并处理分页接口是个高频需求。公司内部有个报表系统最大页大小100条总量动辄几千那就得翻很多页。我以前自己用HTTP Request写完还得在Function里写一堆循环拼接逻辑。用Aggregate之后的流程简洁很多HTTP Request请求第一页拿到总数后算出总页数用Loop Over Items生成页码序列循环里请求每一页数据循环结束后直接把所有分页数据聚合起来。这些步骤看着平平无奇但配合Aggregate之后整个流程从命令式编程变成了数据流编程——你不需要关心数组怎么append、变量怎么存储n8n的数据管道天然帮你做了这件事。我印象很深的一次是处理两千多条分页数据原本代码版本要跑20秒聚合后的版本6秒跑完因为省掉了很多不必要的中间处理。3.3 场景三Webhook接收批量数据聚合成一条再传给下游有些时候问题出在数据到了但是结构不对。比如某平台推送的Webhook是逐条触发的同一秒内可能会收到多条但下游接口只接受一个批量JSON数组。这种情况下Aggregate就能完成多条合并成一条批量请求的转换。流程大概是Webhook节点接收到多条item → Aggregate All → 输出一个数组 → HTTP Request把这个数组作为body发出去。注意这里用途有微妙差异前面两个场景是把聚合后的数据写库或存文件这里是把聚合后的数据当请求体。下游接收方的字段结构要和聚合输出保持一致字段名错一个整个批次都会被拒绝。所以我对这种场景的额外建议是聚合节点之后再接一个Set节点做字段映射/重命名保底输出结构稳定。4. 别把Aggregate、Merge、Summarize搞混——三个节点的分工与选型思路新人对这几个节点的困惑非常集中同样是多份数据变一份到底什么时候用哪个我自己总结了一个非常粗但很好记的说法Merge管拼桌子Aggregate管打包Summarize管算账。4.1 Merge节点横向拼接或纵向堆叠Merge节点做的是两个输入源之间的合并。它有多个模式Append模式把第二个输入的所有item追加到第一个输入后面适合把两张结构相同的数据表纵向堆叠Combine模式按主键把两个数据源的字段横向拼接类似SQL里的join。它处理的是两张表/两个集合之间的关系输入通常是两个不同的上游。而Aggregate处理的是同一股数据里的多条item上游通常只有一个输入口。4.2 Summarize节点聚合计算Summarize更偏统计学它能把一组item按字段做分组、求和、平均、计数、最大最小等。举个例子你有100条销售明细想按商品维度统计总销量Summarize是顺手的工具而Aggregate不做数值运算它只是把100条明细打包成一个由100个元素组成的数组。所以两者其实经常组合使用Aggregate出完整的明细数组Summarize出统计结果标量。好多工作流里先Aggregate后Summarize或者先Summarize后Aggregate都有各自适合的情况。简单说数据要以数组形式传给下游时就选Aggregate要对数据做数值聚合分析时就选Summarize。4.3 一个简单的选型判断表我按实际场景做了个优先级参考你的需求建议节点把多条数据合并成一个数组原样保留Aggregate把两个不同来源的数据按主键拼接成一条宽表MergeCombine模式把两批相同结构的数据堆叠在一起MergeAppend模式统计总和、均值、计数、分组计算Summarize按某字段分组后每组输出一个数组AggregateIndividual模式这个表不用背关键心法是看到数组和打包就找Aggregate看到统计和分组计算就找Summarize看到两张表互相有关联就找Merge。5. 实战中容易踩的坑表达式引用、空值处理与深层嵌套5.1 引用聚合结果时表达式路径必须匹配输出结构这个坑几乎是每个用Aggregate的人都会踩一遍。假设你用Aggregate All并且勾选了合并到单个item那下游表达式引用时你要访问的是$json.fieldName数组里的元素例如引用整个聚合后的数组{{ $json.orders }}引用数组里第一个元素的某字段{{ $json.orders[0].orderId }}把整个数组变成JSON字符串发给接口{{ JSON.stringify($json.orders) }}。如果你没勾选合并到单个item输出本身就是数组形态那下游节点看到的$json是数组的第一个元素而不是整个数组想拿完整数组时要用$input.all()这类上下文方法。这个区别特别容易让人懵。我自己的经验是实在不确定时可以挂一个Set节点先console.log一样的把数据打印出来n8n里可以用Code节点或直接跑一次工作流看输出。调试成本并不高但能省下很多瞎猜的时间。5.2 字段缺失导致数组长度不一致的隐性风险前面提到合并到单个item时n8n会按所有这些item出现的字段并集来生成字段缺失位置用null/空值填充。这是隐藏风险的来源如果其中某个item的某个字段是缺失的你聚合后拿到的数组长度和别的字段不完全对齐后续做zip操作时数据就错位了。举一个真实例子。我在处理两个渠道的订单数据时渠道A有refund_amount字段渠道B没有聚合后refund_amount数组在渠道B的位置全是空值。下游写入数据库时如果直接遍历可能把空值覆盖成0语义上虽然说得过去但统计口径就乱了。建议在聚合之前用Set节点把缺失字段补齐为默认值这样聚合结果才没有坑位。5.3 聚合之后的空数组处理有没有无数据的分支还有个容易被忽略的场景假如循环内没有任何数据传入Aggregate的输出是空数组。空数组传给某些数据库写入节点时可能会直接报错或者写入空的无意义记录。我遇到过的实际案例是定时任务跑到深夜上游接口返回了空列表聚合后数组长度为0下游的HTTP Request仍然发了个空数组出去对方接口直接返回400。解决方式有两个在Aggregate后面接一个IF节点判断数组长度是否大于0为空就走单独分支不触发下游请求在聚合前对上游数据做筛选从根上排除没有数据的分支。总之聚合这个操作看起来是无条件的但它默认了至少有一条数据的前提一旦数据源抖动空数据的case必须纳入设计。5.4 嵌套聚合聚合之后再聚合有的场景需要两层甚至更多层聚合。比如先按订单聚合所有的商品明细再把所有订单聚合起来形成报表。这在n8n里是完全可行的但嵌套层级一旦多起来表达式的可读性会急剧下降数组套数组套对象的结构写错一层路径就取不到值。我处理这种复杂嵌套时有个习惯每层聚合之间用Set节点重新命名并拍平结构比如第一层聚合后字段叫order_items第二层聚合后再包一层叫report_orders。这样虽然节点多了但每一步结构都清清楚楚排查问题时省心太多了。6. 与Function/Code节点脚本的取舍——什么时候Aggregate不是最佳选择虽然标题叫数据聚合神器但我得诚实说一句Aggregate并不是所有聚合场景的最优解有些情况下用短小的Code节点反而更合适。适合用Aggregate的场景是数据结构规整、聚合逻辑简单比如全合并或按字段分组、下游消费方明确需要一个数组。它的好处是声明式、可视化别人看你的工作流时一目了然不需要点开代码去理解你在做什么。那什么时候Aggregate会显得力不从心呢聚合逻辑需要复杂的自定义规则比如跨字段的合并、条件性抽取、按某种权重合并用Code节点只需要10行用Aggregate可能要配置半天数据在聚合时需要调用外部函数或做字符串变换比如每个字段要做URL encode、时间换算等Code节点的“你在做什么”一目了然聚合结果要同时输出多种结构一边要数组一边要对象一个Aggregate做不到Code节点可以灵活返回多个输出项。我的选择逻辑很简单如果聚合后下游要接数据库批量写入、要生成报表、要发Webhook我优先用Aggregate清晰且可维护如果聚合只是一个中间过程后面还要做一堆数据清洗和变换我就用Code节点一把梭省得在节点间来回倒腾。说句题外话n8n的哲学原本就是让数据流变得可见——能用节点表达的尽量别用代码藏着。但工作流里时不时也会混进一些代码表达更自然的需求。我对两者的态度是都掌握别走极端。7. 进阶组合拳Aggregate Code 实现复杂数据清洗7.1 聚合后针对数组做映射而不是映射后再聚合很多人在代码里习惯先映射再合并但在n8n工作流里顺序上存在一个很好的进阶技巧先聚合再映射。聚合之后的数组作为整体传给Code节点你可以在Code节点里一次性完成数据清洗、字段重命名、嵌套结构调整、补充计算字段。这样做的好处是循环内逻辑少、总运行次数少只对一次大数组做操作、代码可读性高。比如聚合后拿到一个订单大数组然后在Code节点里const orders $input.all().map(item item.json); // 清洗去掉不需要的字段 const cleaned orders.map(o ({ orderId: o.order_id, customerName: (o.customer || {}).name || 未知, totalAmount: Number(o.amount || 0).toFixed(2), createdAt: o.createdAt ? new Date(o.createdAt).toISOString() : null, })); // 补充统计字段 const summary { totalOrders: cleaned.length, totalAmount: cleaned.reduce((sum, o) sum parseFloat(o.totalAmount), 0), }; return [{ json: { items: cleaned, summary } }];这样写的好处是聚合器的输出是干净的原始数组Code节点负责业务加工分工明确。调试时我甚至可以先跑一遍看聚合输出是否符合预期再检查代码逻辑问题一下子就隔离了。7.2 通过Aggregate将多路并行数据汇聚到同一分支n8n里还有个比较野的玩法用多个上游分支各自跑完流程后通过Aggregate把不同分支的结果汇聚到一个节点常见于或逻辑的并行分支。比如一个工作流有两个分支一个是实时查询主库存一个是查询备用库存两边都可能返回数据。中间用Switch做了分流两个分支末尾都接同一个Aggregate节点后面再统一处理就很自然。这种用法其实和Merge的Append模式有点像但Aggregate的优势在于它本身不关心数据来自几个上游天然地把所有传入数据打包成一个数组。下游如果要遍历结果可以直接遍历这个数组不用区分数据来自哪条路径。这对失败重试、多源兜底这类场景非常友好。7.3 性能方面的心态建设最后聊聊性能。很多初学者担心Aggregate把大量数据集中到一个节点会拖慢流程。实际上n8n的数据流本身就是内存中传递的聚合并不会显著增加内存占用反而通过减少下游请求次数能大幅提升整体效率。所以该用就用别顾虑太多。真正需要担心的反倒是循环里频繁调用外部API那才是性能黑洞Aggregate是来救场的不是来添乱的。8. 踩坑实录一次真实订单汇总故障的排查过程拿我自己的一个真实经历来做收尾可能最直观。有一次给客户搭了个定时汇总工作流每天凌晨把前一天的订单按店铺汇总后推送报表。上线前测试都正常跑了几天后突然有客户反馈报表数据对不上少了两家店铺的订单。排查过程大概是这样第一步我先看原始数据源确认那两家店铺当天的订单数据确实存在 第二步看了聚合节点的输入发现数据进来了但问题是这两家店铺的订单走了不同的上游分支而且这两条分支都没有很好地做字段归一化一家店铺的字段叫shopName另一家叫store_name 第三步Aggregate Individual节点按shopName分组时另一家店铺因为字段名不对被分到了空分组里 第四步后面的Summarize分组统计时空分组的汇总结果没有被报表生成逻辑覆盖到于是丢了。这个故障的根子上是因为我在设计时没有做好上游字段统一这件事。修法也很简单在进入Aggregate之前加了一个Set节点做字段映射统一成shopName再重新跑数据立刻全了。这个案例我一直记着就是因为真实环境里不出这种事你很难意识到字段名一致性在可视化数据流工具里会带来这么隐蔽的故障。从那次以后我给自己定了个规矩凡是数据要进聚合节点的上游必须保证字段结构完全一致宁可多花一步Set节点做映射也不图省事直接聚合。这算是Aggregate玩久了才会有的肌肉记忆。希望看到这篇的朋友能直接避开这个坑。