做 n8n 工作流这些年我越来越觉得真正难的不是把数据拉进来而是把几十条甚至几千条记录整理成业务能看懂的样子。Summarize 节点就是为此存在的——它能在不写一行代码的情况下完成数据聚合相当于工作流里内置了一个透视表引擎。你不需要会 SQL也不需要会 JS只要理解字段、分组和聚合函数就能把散乱的 output items 变成可以直接拿去发报表、写数据库、推消息的汇总数据。这篇教程我会从底层逻辑开始把 Summarize 的每个核心参数拆开讲清楚再用一个销售订单汇总的完整示例带你走一遍实操最后把我在真实项目里踩过的坑和排查思路整理成速查表。不管你是刚接触 n8n 的新手还是已经在做自动化业务场景的老手这个节点都值得你花半小时彻底搞懂。1. Summarize 节点到底在解决什么问题1.1 一个真实抓狂场景假设你在帮电商业务搭一个自动播报工作流每天定时去订单系统拉当天订单然后发一条汇总消息到企业微信或者钉钉。上游接口返回的是这样一组数据{ order_id: 1001, customer: Alice, amount: 120, status: paid, region: 华东 }但这只是其中一单接口会返回几十条甚至几百条。如果你直接把数据接到消息节点n8n 会按“每个 item 触发一次”的逻辑给每个订单都单独发一条消息。你本来只想发“今日订单 25 单销售额 8900 元”结果群里刷了 25 条消息运维和运营集体崩溃。遇到这种情况第一个想到的方案是写一个 Function 节点用 JSreduce()手动累加。这当然能做但每次改需求都要回到代码里调而且不是所有人都愿意维护一段散落在流程里的 JS。Summarize 节点就是专门解决这个问题的它把“多条 item 输入”变成“一条聚合 item 输出”或者按指定维度变成“多条分组汇总 item 输出”。1.2 数据聚合的本质把多行变成一行或几行n8n 的核心数据模型是一个数组式的 item 流每个节点接收上游传来的多个 item处理后继续往下传。大多数节点对 item 是“一对一”或者“一组对一组”的处理逻辑但 Summarize 的工作方式是“多对一”或“多对多”的变换。你可以把它想象成 Excel 里的透视表或者 SQL 里的GROUP BY。输入是一张大宽表每条订单占一行输出是一张汇总表每一行代表一个分组列是订单数、总金额、平均金额这些统计指标。它最常见的三种输出形态不分组所有订单合成一条汇总记录比如总单数、总金额。按维度分组按region分组得到每个区域一条汇总记录。多字段分组按region status分组得到每个区域、每个订单状态一条汇总记录。理解了这一点你就掌握了这个节点的灵魂它不是在给数据“美容”而是在对数据做降维和提炼。平时工作流里那些“算总数”“算平均值”“按类别统计数量”的需求本质上都是这个动作。2. 核心参数拆解五个关键点帮你搞定90%聚合场景2.1 Operation先选 Group 还是 Append在 Summarize 节点最上方的 Operation 下拉框里一般能看到两种模式Group 和 Append。这里要特别注意二者解决的问题是不同层级的。Group 是核心也就是分组聚合。你告诉 n8n“按这些字段分组然后对组内数据做求和、计数、求平均等操作。”这是你日常处理数据统计时默认、也是最常用的模式。Append 模式的逻辑则是把所有输入 items 合并成一个 item。比如你有三条数据字段分别是name和valueAppend 会把它们变成一个包含数组的 itemname: [a, b, c]。它适合“把散开的记录收集成一个数组”的场景但并不适合做统计计算。如果你只是想拼数组我其实更建议直接用 n8n 的 Aggregate 节点那个表达更直白。Append 在 Summarize 里偶尔会用到但别指望它帮你算平均值。我自己的习惯是90% 的情况毫无悬念地选 Group只有极少数需要把上游多路输出合并成一个 list 的场景才会碰 Append。2.2 Fields to Group By分组的维度和表达式这个字段是整个聚合的“分桶依据”。你填什么输出就按什么分类。它支持两种填法写普通字段名例如region。写表达式例如{{ $json.category }}或者更复杂一点的{{ $json.year - $json.month }}。我强烈建议你养成“先看上游数据结构再填分组字段”的习惯。在 n8n 的编辑面板里点开上方输入数据预览能看到上游节点的实际输出字段直接点字段名就可以把它插入到 Group By 里既快又不拼错。还有一个很容易被忽略的细节Group By 支持填写多个字段用英文逗号分隔。例如region,statusn8n 会按这两个字段的组合来分组。它不是做嵌套层级而是生成“唯一组合”的多个分组。后面实操部分我会演示这个效果。如果分组字段的值是null或者字段根本不存在n8n 会单独给它分一个组。这听起来合理但在实际业务里空值分组往往会干扰下游判断。最简单的办法是在上游用表达式把空值统一成一个默认值比如{{ $json.region || 未知地区 }}。2.3 Aggregations聚合函数与来源字段这一块是 Summarize 真正干活的地方。你可以点 Add Aggregation 添加一个或多个聚合规则每条规则都由三部分组成Source Field来源字段告诉节点“我要加工哪个字段”。Aggregation Function聚合函数告诉节点“对这个字段做什么操作”。Output Field Name输出字段名告诉节点“结果叫什么名字”。常用聚合函数可以整理成一张表聚合函数作用典型场景Sum对来源字段求和总销售额、总耗时Average求来源字段的平均值客单价、平均响应时间Min求最小值最低价格、最早时间Max求最大值最高评分、最新订单Count统计 item 条数订单总数、报名人数Count Unique对来源字段去重后计数独立用户数、唯一门店数Concatenate把来源字段的所有值拼接成一个字符串拼接所有商品名Longest取来源字段中最长的文本找出最长的备注Shortest取来源字段中最短的文本找出最短的名称这里有个容易踩坑的点Count 和 Count Unique 的含义完全不同。Count 不关心来源字段内容它就数“有几条 item”而 Count Unique 需要指定一个来源字段然后数“这个字段里有多少个不重复的值”。比如你有 20 条订单记录其中 5 个不同用户下的单Count 会输出 20Count Unique 对customer字段计算会输出 5。如果业务要“客户数”一定要用 Count Unique否则会把重复下单的用户重复算进去。2.4 多个聚合同时计算一次输出多列指标实际项目里很少只算一个数字。你多半需要“总金额 订单数 平均客单价”同时出现在结果里。这完全不需要串联三个 Summarize你只需要在 Aggregations 里依次添加三条规则Source FieldamountFunctionSumOutput Field NametotalAmountSource Fieldorder_idFunctionCountOutput Field NameorderCountSource FieldamountFunctionAverageOutput Field NameavgAmount最后输出的每个分组 item 会包含这三个新字段。这样下游只要对接一次就能拿到整套指标。越是这种“多指标组合”的需求Summarize 相比手写代码的优势就越明显改一个函数、加一个字段都是可视化操作不用重新部署。2.5 Options空值和数字精度的处理很多人在配置 Summarize 时会忽略最下面的 Options 折叠面板但其实很多“看起来结果不对”的问题都出在这里。不同版本的 n8n 在选项名称上会有一点差别但常见的几个逻辑是一样的空值处理可以选择在聚合时忽略null字段也可以保留并单独分组。数字精度有些场景希望金额保留两位小数可以在 Options 里打开 Round 相关选项或者用表达式{{ Math.round($json.totalAmount * 100) / 100 }}做二次加工。输入为空时的行为如果上游没有任何 itemSummarize 往往不会执行或者只会产生一个空汇总。建议在敏感流程里用 If 节点先判断“items.length 0”再走汇总分支。我把这些选项统称为“守护配置”。它们的核心价值不是让你多点击而是确保聚合结果在数据质量不理想时依然稳定、可预期。3. 实操从零构建一个销售订单汇总工作流3.1 造数据用 Code 节点模拟订单数组看参数不如动手跑一遍。我从一个最常见场景开始模拟一个订单接口返回数据然后用 Summarize 按区域统计销售额和订单数。先在工作流里加一个 Manual Trigger然后接一个 Code 节点写入这段测试数据return [ { order_id: 1001, customer: Alice, amount: 120, status: paid, region: 华东 }, { order_id: 1002, customer: Bob, amount: 80, status: pending, region: 华北 }, { order_id: 1003, customer: Carol, amount: 200, status: paid, region: 华东 }, { order_id: 1004, customer: Dave, amount: 50, status: paid, region: 华北 }, { order_id: 1005, customer: Eve, amount: 130, status: pending, region: 华东 }, { order_id: 1006, customer: Frank, amount: 90, status: paid, region: 华南 }, { order_id: 1007, customer: Grace, amount: 160, status: paid, region: 华东 }, { order_id: 1008, customer: Hank, amount: 70, status: pending, region: 华南 } ];如果你已经有了生产环境的数据源这一步可以替换成 HTTP Request、Webhook 或数据库查询节点。测试阶段用固定数据的好处是结果可预期你一眼就能看出节点配置是否配对了。3.2 配置 Summarize 节点分组、求和、统计数量在 Code 节点后面拖一个 Summarize 节点开始配置Operation 选择Group。Fields to Group By 填region。添加第一个 AggregationSource Field 填amountAggregation Function 选SumOutput Field Name 填totalAmount添加第二个 AggregationSource Field 填order_idAggregation Function 选CountOutput Field Name 填orderCount点击 Execute Node 执行。这里我特意用order_id作为 Count 的来源字段是因为每条订单都有订单号用它来计数语义上最安全。Count 函数其实不依赖字段内容但选一个“必然存在的字段”可以让后来看流程的人更容易理解。执行完成之后数据变成了这样[ { region: 华东, totalAmount: 610, orderCount: 4 }, { region: 华北, totalAmount: 130, orderCount: 2 }, { region: 华南, totalAmount: 160, orderCount: 2 } ]原本 8 个订单 item 变成 3 个区域汇总 item。下游无论是发消息、写 Excel 还是推送数据看板都只需要处理这几行数据了。3.3 验证结果输出字段和实际数据结构很多人配完 Summarize 之后喜欢直接在节点里看“美丽的数据”但对接下游时才发现字段名不对。实际上Summarize 的输出字段就是你刚才在 Output Field Name 里写的名字而不是原来的amount或者order_id。也就是说下游节点看到的是totalAmount和orderCount不是amount。如果你在下游想引用金额不要再写$json.amount而要写$json.totalAmount。用 n8n 表达式时就是{{ $json.totalAmount }}这一点非常重要。我见过太多人配置完 Summarize 后报“字段不存在”其实并不是节点坏了而是他还在用旧字段名。建议对接下游前先用一个 Set 节点把字段名重新映射成业务口径例如把totalAmount改成total_sales_amount这样下游数据库和接口不会因为 n8n 流程调整而频繁改动。3.4 多字段分组按区域加状态统计刚才按region分组只统计了区域维度。实际业务经常要同时看“每个区域里已支付和待支付各有多少单”。这时只需要把 Fields to Group By 改成region,status再执行一次结果变成[ { region: 华东, status: paid, totalAmount: 480, orderCount: 3 }, { region: 华东, status: pending, totalAmount: 130, orderCount: 1 }, { region: 华北, status: pending, totalAmount: 80, orderCount: 1 }, { region: 华北, status: paid, totalAmount: 50, orderCount: 1 }, { region: 华南, status: paid, totalAmount: 90, orderCount: 1 }, { region: 华南, status: pending, totalAmount: 70, orderCount: 1 } ]这种“多字段组合分组”非常适合做二维报表。下游再用Filter节点筛选特殊分组或者直接丢到表格里做透视图都能省掉大量二次处理。注意它不是先按区域分一层、再按状态分一层的嵌套结构而是直接把每个“区域 状态”组合作为一个独立分组输出。3.5 二级聚合把汇总结果再汇总有些需求单靠一层 Summarize 还解决不了。比如你要看“所有区域的平均销售额”和“所有区域的总销售额”但你不想手动把上游数据再复制一份。最清晰的做法是串联两个 Summarize 节点。第一个 Summarize 按region分组算出每个区域的totalAmount和orderCount。第二个 Summarize 接在它后面不填 Group By直接对totalAmount做 Sum 和 Average得到{ allRegionTotal: 900, allRegionAverage: 300 }这种“先分组、后汇总”的二级聚合在月报、季度汇总、部门绩效统计场景中特别常见。它比写一个复杂嵌套表达式更直白排错也更容易。4. 常见问题与排查技巧实录4.1 为什么聚合后没有任何输出最常见的翻车现场是上游接口返回空数组或者请求失败导致没有 item 到达 Summarize。如果上游节点本身因为报错而中断Summarize 根本不会执行这时候你要去上游看日志而不是改 Summarize 配置。另一种情况是上游确实输出了 item但你在 Fields to Group By 里填的字段名和实际不一致比如实际字段叫Region你填了regionn8n 找不到匹配字段就会把整个数据当一个组合并到一起看起来像“没有按预期分组”。解决方法是先在上游节点执行一次打开输入数据预览用点选方式插入字段名不要凭记忆手敲。我个人的建议是在 Summarize 前面加一个 If 节点判断{{ $items.length }} 0为 0 时走空数据处理分支避免把空结果带入下游业务模块。4.2 Sum 把数字拼成了字符串如果你对字段做 Sum结果不是数字加和而是12020090这种诡异拼接那大概率是上游字段类型是字符串。n8n 里从 JSON 接口和 Webhook 拿到的字段很多时候是字符串虽然看起来像数字但类型不对会导致聚合行为变成文本拼接。解决办法是在 Summarize 之前用 Set 节点做类型转换或者直接在聚合规则的 Source Field 里用表达式{{ Number($json.amount) }}如果还需要保留小数精度可以配合 Options 里的 Round 选项或下游表达式做二次处理。我建议所有金额字段在进入聚合前都统一为数值类型这是避免“幽灵 bug”的最有效手段。4.3 分组字段值不一致导致的“幽灵分组”shanghai和Shanghai会被视为两个不同的分组上海和上海 也会分成两条。这类问题在人工填报数据来源里非常常见。解决方式是做分组口径清洗。与其在多个流程里反复修数据不如在 Summarize 前用一个表达式统一字段值{{ $json.region.trim().toLowerCase() }}如果你需要对中文文本做更精细的清洗也可以先用 Set 或 Code 节点做统一映射比如把所有上海、上海市、上海 都规整成上海。分组字段的质量直接决定聚合结果的质量。4.4 性能变慢数据量大时怎么优化Summarize 节点本身对几千条 item 的处理速度很快真正拖慢流程的往往是“数据还没有聚合就被传到了慢节点”比如循环、HTTP 请求、甚至写数据库操作。优化原则很简单越早聚合越好。我给你列几条实操习惯在上游 SQL 节点里能直接用GROUP BY就先做掉n8n 只处理剩下的计算。尽量不要把大宽表的所有字段全部传到 Summarize可以在前面加一个精简字段的步骤只保留参与分组和聚合的字段。如果一次要处理十万行以上的数据建议优先用 Code 节点配合内存计算或者直接把计算任务下推给数据库Summarize 更适合几千条到几万条的日常规模。我测试过用 Summarize 处理两三万条 JSON 数据基本不会成为性能瓶颈。瓶颈往往出现在你把它放在循环之后、还有大量 HTTP 请求的场景那种架构问题就不是一个聚合节点能救回来的了。4.5 问题速查表这里整理一份我在群里经常回复的速查表方便你直接对照排查现象可能原因解决思路聚合结果为空上游没有数据或字段名不匹配检查上游执行用预览点选字段Sum 输出了字符串拼接字段类型是字符串用Number()或 Set 转类型Count 数值比预期大把 Count 当成了 Count Unique按需改用 Count Unique分组过多、过碎字段值大小写/空格/null 不一致做 trim、toLowerCase 和空值映射下游找不到聚合结果字段还在用旧字段名使用 Output Field Name 的新名字Append 模式下无法计算用错了模式统计计算请使用 Group 模式这些坑不踩一遍很难记住所以我建议你把速查表收藏起来或者直接贴到自己的 n8n 知识库里下次遇到类似问题直接按图索骥。5. 写在最后的实战心得最后分享一个我自己的小习惯每次配置 Summarize 之前我一定会先花十秒钟看上游输入数据的类型和示例值。很多问题不是节点不会用而是对输入数据不够了解。你只要知道字段是字符串还是数字、是否存在空值、命名是否规范聚合配置基本一次就能成功。另一个心得是给聚合结果起“人话字段名”。SUM_amount这种名字虽然不影响程序但三个月后你自己回来维护流程看到totalSalesAmount肯定比看sum_amount_1顺畅得多。字段名写清楚比多写注释管用。我之前在一个项目里用 Summarize 把原本要循环发送 20 多条通知的流程压缩成了一条汇总消息下游的数据库写入也从每单一条变成了每天一条。这个节点不复杂但它真正改变了 n8n 工作流处理批量数据的方式。希望这篇教程能帮你用好这把数据聚合的“魔法武器”。