Split out: Destination field name does not support dot notation

问题场景

用户在自托管 n8n 中使用 Split Out 节点拆分数组数据时，把“Destination Field Name”设置为带点的 data.foo，希望拆分结果写入 data 下的 foo 键，但实际得到的是一个名为 data.foo 的顶层键，而不是嵌套结构。该问题在“Disable Dot Notation”关闭的状态下依然存在。

报错原文

Split out: Destination field name does not support dot notation

原因分析

最可能的原因是 Split Out 节点在写入“Destination Field Name”时没有把点号解析为路径分隔符，而是把整个 data.foo 当作字面量键名处理。也就是说，即使“Disable Dot Notation”处于关闭状态，该节点也没有按路径语义写入嵌套字段。

按照 Issue 中的反馈，这可以理解为一种“路径契约 vs 字面量键”的不一致：操作者认为点号表示路径，但节点按字面量键处理，导致数据结构与预期不符。由于节点本身不会在配置或执行时报硬错误，问题往往直到下游节点消费数据时才暴露。

环境排查

• 确认 n8n 版本：Issue 中为 2.20.7。
• 确认部署方式：Issue 中为 Docker 自托管。
• 确认操作系统：Issue 中为 Ubuntu 24.04。
• 确认 Node.js 版本：Issue 中为 24.14.1。
• 确认数据库：Issue 中为 PostgreSQL。
• 确认 Split Out 节点中“Fields to Split Out”与“Destination Field Name”的实际取值。
• 确认“Disable Dot Notation”开关状态；Issue 中该开关关闭时问题仍存在。
• 确认下游节点（Set/IF/Code 等）读取的是 data.foo 嵌套路径还是字面量键。

解决步骤

1. 先复现并确认数据形状：运行 Split Out 节点后，检查输出 item 的键名。如果看到的是字面量 data.foo 顶层键，而不是 data 下嵌套的 foo，说明点号没有被解析为路径。
2. 可优先尝试规避写法：把“Destination Field Name”改为不带点的名称，例如 foo，让 Split Out 先把拆分结果写到该键。
3. 如果最终数据需要嵌套在 data 下，可在 Split Out 之后接一个 Set 节点，手动构造 data.foo 的嵌套结构。
4. 如果业务上依赖点号自动解析为路径，可把当前行为视为契约问题，在测试工作流中固定预期输出形状，避免直接在生产工作流中依赖该行为。
5. 关注官方修复进展：Issue 已进入内部跟踪（Linear 引用 GHC-8927），在官方修复发布前，建议保持上述规避方案。

验证方法

运行包含 Split Out 节点的工作流后，检查输出 item 的键：若 data 下出现嵌套的 foo 键，则符合预期；若仍出现字面量 data.foo 顶层键，则问题未解决。使用规避方案时，确认下游 Set/IF/Code 节点能按新结构正确读取数据。

参考来源

n8n-io/n8n #34053

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。