最近在折腾 n8n 工作流的时候，我把大量时间花在了数据结构转换上，尤其是列表分割。n8n 里的 Split Out 节点，就是专门用来把列表拆成单个项目的工具，配合 n8n credentials 配置好数据源之后，你可以在 n8n 工作流里非常高效地处理订单、用户、消息这类批量数据。这篇文章就围绕 Split Out 节点，把列表分割的原理、配置、实操和常见坑一次讲透。
我自己接手过很多 n8n 项目，最早接触这类数据时也绕了远路：拿到一个数组字段，先想用 Loop 循环，后来又纠结 JSON 解析，最后发现 Split Out 才是那个最直接、最省事的节点。它对新手友好，对有经验的人也很实用。今天这篇内容没有废话，全部是实测过的经验，你照着配置就能跑通。
1. 为什么需要 Split Out：列表分割的工作流场景
1.1 几乎所有 n8n 工作流都会遇到的数据形态问题
n8n 工作流最大的魅力在于把不同系统串起来，但系统之间传过来的数据往往不是我们想要的“单条数据”，而是“一堆数据”。举个例子，你从 HTTP Request 节点请求一个电商订单接口，返回的 JSON 通常是：
{ "orders": [ { "id": 101, "customer": "张三", "total": 299 }, { "id": 102, "customer": "李四", "total": 159 }, { "id": 103, "customer": "王五", "total": 89 } ] }如果你想把每个订单单独发送到企业微信、单独写入数据库、单独生成 PDF 对账单，你面对的第一个问题就是：n8n 里很多节点一次只能处理一个项目。即使有些节点支持批量处理，你依然需要在“整体列表”和“单项数据”之间做一次转换。
Split Out 节点就是解决这个转换问题的。它可以把一个包含数组字段的 Item，拆成多个 Item。每一个 Item 代表原数组中的一个元素，并且保留你在配置中指定保留的字段。换句话说，它把“一箱货”拆成“一件一件货”，让下游节点可以逐件处理。
很多人会问：既然 n8n 已经支持批量调用，为什么还需要拆开？因为下游系统往往有频率限制，比如企业微信机器人一次只能发一条消息；或者你需要在循环中对每一条数据做不同的分支判断；又或者你需要在拆分之后的每条数据上附加不同的标签。这些场景下，“逐条处理”就是刚需，而 Split Out 正是为这个需求设计的。
1.2 Split Out vs Loop：它们的区别和选择
刚接触 n8n 的时候，我看到“循环”本能地想到 Loop Over Items 节点。确实，Loop 也能把一个列表逐条送进循环体处理。但它和 Split Out 的使用场景有本质区别。
Loop Over Items 更适合需要“对每条数据做一套复杂流程”的情况。比如你需要依次处理 100 个文件，每个文件都要：下载 → 解析 → 转换 → 上传 → 记录结果，而且中间需要维护循环状态、计数、是否出错重试，这时候 Loop 更合适。
Split Out 则是个“一次性分裂”节点。它不产生循环体，而是直接把列表展开成多个 Item 同时输出。输出结果直接连接到下游节点后，下游节点天然会对每一个 Item 执行一次处理。这就像把一条装配线上的“整箱零件”拆成“单个零件”，后面的工位自动逐个加工，不需要你手动控制循环。
我用一个对比表格来展示它们的关键差异：
| 对比维度 | Split Out | Loop Over Items |
|---|---|---|
| 数据输出方式 | 一次性展开，多个 Item 同时输出 | 逐次进入循环体，依次处理 |
| 适合场景 | 简单的批量转逐条操作 | 复杂流程、需要循环控制 |
| 配置复杂度 | 低，只需选择字段和选项 | 高，需要配置循环次数、收集器等 |
| 对下游节点影响 | 下游自动处理每个 Item | 下游在循环体内运行，需注意变量作用域 |
| 性能表现 | 快，一次性完成拆分 | 较慢，循环次数越多耗时越长 |
所以我的建议是：如果只是“把数组拆开”，优先选 Split Out；如果涉及“每一条数据都要跑一套流程”，才考虑 Loop。实际工作中，这两种方式常常搭配使用：先用 Split Out 把列表展开，再配合条件分支对每条数据做不同处理。
2. Split Out 节点配置细节与参数取舍
2.1 最核心的 Split In：选择列表字段
Split Out 节点的配置面板里，最核心的就是 Split In 字段。这个字段指定你要拆分的数组来自哪里。
默认情况下，Split In 可以选择 JSON Output、Parameter Options 等方式。实际使用中，最常见的是“JSON Output”，即从当前输入数据中选择一个数组字段。你可以在下拉框里看到当前数据中所有的顶层字段。比如前面那个订单接口，数据格式是{ "orders": [...] }，你直接选择orders即可。
如果你传入的数据结构更复杂，比如接口返回：
{ "data": { "list": [ { "name": "项目A", "score": 88 }, { "name": "项目B", "score": 92 } ] } }那么 Split In 需要选择data.list。n8n 的字段选择器支持点号路径，展开data再选择list，节点就能正确识别这是一个数组类型。注意一点：如果选择的字段不是数组，Split Out 会报错，提示你选择的字段类型不匹配。因此在配置之前，最好先用 Code 节点或者 Item List 节点检查数据类型。
还有一个重要细节：Split In 也可以选择“多个字段”。当选择Multiple模式时，你可以同时拆多个字段，输出会按照“每个字段分别拆分”的方式生成多个 Item。这个功能适合数据中存在多个独立列表的情况。比如一个接口同时返回newOrders和returnOrders，你想把两类订单都拆出来处理，用 Multiple 模式可以一步到位。
2.2 Split Out 选项详解：保留字段、拆分成单次还是全部
Split Out 的 Options 里有几个容易被忽略但实际很重要的设置。
首先是Options > Keep Parent。开启后，拆分出来的每个 Item 会自动带上父级数据中的原始字段。还是以订单接口为例，如果原始数据里除了orders数组，还有一个shopName字段，你想让拆出来的每个订单都保留这个shopName，那就开启 Keep Parent。这在多店铺数据处理时非常实用，拆完之后的每个订单依然能知道它属于哪个店铺。
其次是Options > Destination Key Name。默认情况下，Split Out 拆出来的数据会保持原有的字段名，比如id、customer、total。但如果你想要把拆出来的整条数据放到一个新的字段下，比如orderItem，则可以设置这个选项。某些下游节点读取固定字段时，这个配置能帮你省掉一个“聚合/修改字段”节点。
然后是Options > Split。这里有两种模式：Split Into Items和Split Into Batches。前者就是我们前面说的“拆成单个 Item”，后者是把大列表拆成若干个小批次，每批次包含 N 条数据。Split Into Batches在生产环境中很有用，比如对接第三方接口时有“每次最多提交 10 条”的限制，你就用这个模式把列表切成多个数组，再逐个数组批量发送。
最后是Options > Disable Dot Notation。这个选项在字段名本身包含点号时有用。比如数据里的字段叫order.id，如果你不关闭点号标记，n8n 会把order.id解析成嵌套路径，导致找不到字段。遇到这种非常规字段名，勾选这个选项就好了。
我自己在实际项目里最喜欢组合使用 Keep Parent + Split Into Items，这能最大程度保留上下文信息，减少下游节点到处查找关联数据。你可以根据具体业务需求选择，但建议把 Keep Parent 默认开启，除非你要处理的数据量极大、需要节省负载。
3. 实操案例：从订单数据到逐条消息
3.1 场景设定：一个真实可复现的订单通知工作流
为了让你看得更明白，我构建一个典型场景：每天早上 9 点，从一个模拟订单接口拉取当天的订单列表，然后通过企业微信机器人逐条发送订单通知。完整流程是：
- 使用 Schedule Trigger 定时触发。
- 使用 HTTP Request 拉取订单列表。
- 使用 Split Out 将订单列表逐条拆分。
- 使用 Webhook 节点或 HTTP Request 发送企业微信机器人消息。
在这个场景里，Split Out 就是关键转换节点。没有它，你很难把“列表”变成“逐条发送”。
假设接口返回的数据格式如下：
{ "shopName": "示例店铺", "orders": [ { "orderId": "A1001", "customer": "张三", "amount": 299, "status": "paid" }, { "orderId": "A1002", "customer": "李四", "amount": 159, "status": "paid" }, { "orderId": "A1003", "customer": "王五", "amount": 89, "status": "refunded" } ] }我们需要把orders拆出来，每条订单变成一个 Item，并且保留shopName。这样发消息时，消息内容里既能带上订单详情，也能带上店铺名。
3.2 分步搭建：从 HTTP Request 到 Split Out 到消息发送
第一步：配置 HTTP Request 节点
- Method 选择 GET。
- URL 填写模拟接口，比如
https://api.example.com/getDailyOrders，或者你本地的 mock 地址。 - Response Format 选择 JSON。
- 收到数据后，你可以在节点输出中看到完整的
shopName和orders数组。
第二步：配置 Split Out 节点
- Split In 选择
orders。 - Options 开启 Keep Parent，这样
shopName会被保留。 - Options 保留默认的
Split Into Items。
配置完成后，你可以点击“Execute Node”测试，输出结果会变成三个 Item：
| Item 编号 | shopName | orderId | customer | amount | status |
|---|---|---|---|---|---|
| 1 | 示例店铺 | A1001 | 张三 | 299 | paid |
| 2 | 示例店铺 | A1002 | 李四 | 159 | paid |
| 3 | 示例店铺 | A1003 | 王五 | 89 | refunded |
第三步：配置消息发送节点
在企业微信机器人发送文本消息时，你可以用表达式引用当前 Item 的字段：
订单号：{{ $json.orderId }} 客户：{{ $json.customer }} 金额：{{ $json.amount }} 元 店铺：{{ $json.shopName }} 状态：{{ $json.status }}因为 Split Out 已经把列表拆开成单个 Item，Webhook 节点或 HTTP Request 节点会对每个 Item 执行一次请求。你不需要额外写循环。
第四步：加一个判断，只发送已支付订单
如果只想通知已支付订单，可以在 Split Out 后面接一个 IF 节点：
- 条件：
{{ $json.status }}等于paid。 - 条件成立分支：发送企业微信消息。
- 条件不成立分支：结束或记录日志。
这就是 Split Out 带来的最大便利：列表拆开后，下游的每一个节点天然和“单条数据”配合，逻辑变得非常简单直观。
3.3 验证结果和常见检查点
工作流跑完之后，打开“Executions”页面，点击一次执行记录，你可以看到三步的关键结果：
- HTTP Request 输出只有 1 个 Item，包含整个列表。
- Split Out 输出有 3 个 Item，每个 Item 里的字段完整且保留
shopName。 - 消息发送节点执行了 3 次请求，如果加了 IF 节点则只有 2 次请求。
这个验证习惯很重要。很多人配置完 Split Out 后不看中间输出，直接看最终结果，一旦下游节点报错就满工作流排查，效率很低。我习惯在拆分后加一个“只看不发的调试节点”或者直接点击每个节点查看执行数据，确认拆分正确以后，再去排查下游逻辑。
4. 常见问题与排查技巧实录
4.1 拆分后字段丢失，怎么办
这是最常遇到的问题。配置了 Split Out 之后，下游节点里引用不到原本列表之外的字段。原因很简单：你没有开启 Keep Parent。Split Out 默认只输出列表元素，列表之外的同级字段不会自动保留。
解决办法是打开 Options 里的 Keep Parent。开启之后，输出字段会变成“原父级字段 + 数组元素字段”的合并结构。如果你不想保留全部父级字段，而是只想带出某一个，可以用 Code 节点先整理数据结构，再交给 Split Out。
另外要注意，如果父级数据和数组元素存在同名冲突，比如父级里有一个id，数组元素里也有id，n8n 会优先保留后者的值。遇到这种情况，建议在 Split Out 之前用 Set 节点把父级字段重命名，比如改成parentId，避免覆盖。
4.2 嵌套列表和数组字段的拆分
有些接口返回的数据不是简单的一维数组，而是嵌套结构。比如：
{ "customers": [ { "name": "张三", "orders": [ { "orderId": "B001" }, { "orderId": "B002" } ] }, { "name": "李四", "orders": [ { "orderId": "B003" } ] } ] }如果你直接 Split Outcustomers，你会得到两个 Item，每个 Item 里依然带有一个orders数组。如果你想进一步把orders也拆开，可以再接一个 Split Out 节点，Split In 选择orders，同时开启 Keep Parent，保留客户名。这就是串联拆分的思路。
实际项目中，我经常需要把这种“客户-订单”嵌套结构拍平成“每个订单一条数据”，方便写入数据表或发送通知。连续的 Split Out 组合可以完美实现这个需求。有人可能会想到用 Code 节点写 JavaScript 实现拍平，但用 Split Out 的方式更直观，也更适合后来人接手维护。
4.3 Split Out 与聚合节点的搭配使用
拆分之后，有时候你还想把数据再聚合回去。n8n 里对应的是 Aggregate 节点。比如你先把一个大列表拆成多条，给每条数据做异步处理，然后再把所有结果汇总成一个列表，供下游批量调用或保存。Split Out 和 Aggregate 互为逆操作，它们的搭配可以解决很多数据转换问题。
聚合节点的常用设置是按某个字段聚合。例如你有一批订单消息，每条消息包含shopName和content，你想按店铺分组，把消息内容聚合成一个数组。在 Aggregate 节点的 Aggregation 选项中选择Append，Group By 选择shopName，最后输出就是每个店铺一条数据，每条数据里包含该店铺所有消息内容的数组。
这里有个坑：聚合之后，Item 数量变少，下游如果期望“逐条发送”，你又得再拆一次。所以一定要先明确目标节点的输入形态，再决定是否聚合。我见过不少开发者因为来回切换 Split Out 和 Aggregate 导致性能下降，最后发现其实数据结构一开始设计好，根本不需要来回转换。
4.4 处理空数组和异常数据
Split Out 遇到空数组时不会报错，但输出结果是零个 Item。这在大多数时候是好事，因为下游不会执行多余操作。但如果你需要知道“这次没有新订单”，空结果会让通知链路“静默失败”。我用过两种处理方式：
- 在 Split Out 前用 IF 节点判断数组长度。如果
orders.length > 0，才进入拆分流程；否则走另一个分支发“今日无订单”的通知。 - 使用聚合节点把拆分结果收集起来，再判断收集后的 Item 数量。
这两种方式都可以，我更推荐第一种，因为前置判断更直观，也不容易误触发下游节点。
另外要特别留意数组里可能出现的null或字段缺失。上游接口不稳定时，某些订单可能没有customer字段，下游文本模板里引用{{ $json.customer }}会出现空白。建议在 Split Out 后加一个 Set 节点，把关键字段填充默认值，或者用表达式做空值兜底。
4.5 性能优化与大批量数据拆分
Split Out 在处理几千条数据时完全没有压力，但如果一个数组有几万条，拆分后下游每个请求都可能成为瓶颈。比如发邮件接口限速每秒 5 条，那 2 万条数据要跑很久。我的经验是：
- 先用
Split Into Batches把大列表切成小批次，每批 50 或 100 条。 - 下游用批量接口一次处理一批，而不是逐条请求。
- 如果必须逐条处理，可以在关键节点之间添加 Wait 节点，控制速率。
企业级 n8n 部署方案里，这种操作通常还要搭配队列模式，避免一次执行占满所有 Worker。关于部署层面，我建议使用 Docker Compose 自托管 n8n，将 Executions 数据独立存储到 Postgres，工作队列独立出来，这样大批量拆分执行不会拖垮 UI 响应。n8n credentials 的加密密钥也不要到处复制，集中配置到环境变量里，团队协作时再配合共享环境变量或外部凭据管理，避免把密钥写进项目仓库。
5. 我的实操体会与扩展建议
Split Out 看起来只是一个简单的“拆分”节点，但它背后代表的是 n8n 工作流里最常见的数据形态转换思想：整体到个体、列表到逐条、批量到单发。掌握它，你就掌握了大部分自动化流程里的中间转换逻辑。我在多个项目里反复用过它，最直观的感受是：很多看起来复杂的流程，一旦把数据拆到“单条”级别，后面的每一步都变得非常清晰。
再分享一个小技巧：如果你处理的字段名经常变化，可以在 Split Out 前面加一个 Code 节点，把动态字段标准化，比如统一命名成item，这样 Split In 永远只选择item，下游表达式也无需频繁改动。这个习惯对于长期维护的工作流特别有用，尤其是别人接手你的项目时，会明显感觉到结构规整。
另外，n8n 中文社区里有很多关于扣子、dify、fastgpt、n8n 这类 AI 工具链的讨论，你可以尝试把 Split Out 用在 AI 消息批量处理场景里：一次读取用户列表，拆分后逐条调用大模型生成个性化文案，再用 Aggregate 聚合成最终报告。这种组合能省掉大量重复工作，也是目前很流行的智能体工作流思路。
希望这篇基于实测的 Split Out 教程能帮你少踩坑。如果你在实际使用中遇到了其它奇怪的数据结构问题，不妨从“先拆分、再处理、最后聚合”这个思路入手，很多问题都会迎刃而解。
