JSON 处理的“黑话”：为什么你的 n8n 工作流总是莫名其妙报错？
作为 N8N大学 的主编，我见过太多新手在处理 API 数据时，对着屏幕上红色的报错信息束手无策。特别是当涉及到 HTTP Request 节点处理 JSON 数据时，那种“明明参数填对了却死活跑不通”的挫败感，笔者太懂了。
今天，我不讲枯燥的理论，只讲实战中踩过的坑。如果你正在为 n8n 的 JSON 处理头疼，这篇文章就是为你准备的“避坑指南”。我们不谈废话，直接上干货。
坑一：路径迷雾——“我明明传的是字符串，为什么报错？”
这是新手最容易掉进去的坑。在 HTTP Request 节点中，当你在 Body 里选择 JSON 类型并输入参数时，n8n 默认会将你输入的内容作为 JSON 对象解析。
如果你的变量（比如来自 Set 节点或上一个节点的输出）本身是一个字符串格式的 JSON（例如 "{\"name\":\"n8n\"}"），直接填入参数框会导致双重转义，n8n 会把它当成一个普通的字符串发送出去，而不是对象。
笔者亲测： 这种情况下，API 接收端通常会报 400 Bad Request，提示 JSON 解析失败。
解决方案：使用 JSON 解析函数
不要直接引用变量。在 HTTP Request 节点的 Body 参数框中，你需要使用 n8n 的表达式函数 json() 来手动转换它。
- 错误写法：
{{ $json.your_field }} - 正确写法：
{{ json($json.your_field) }}
这行代码会强制 n8n 先把字符串解析成对象，然后再作为 JSON 发送。这是处理嵌套 JSON 时的保命符。
坑二：数据扁平化陷阱——丢失的嵌套结构
第二个坑非常隐蔽。有时你的 HTTP Request 发送成功了，但接收方却说缺少字段。为什么？因为 n8n 的 Set 节点在处理多层嵌套 JSON 时，默认行为可能会让你“意外”丢失数据。
当你要通过 HTTP Request 发送一个复杂的嵌套 JSON（比如包含数组或深层对象）时，如果你在 Set 节点里逐个字段手动设置，很容易把结构打散。
解决方案：保持对象完整性
最佳实践是：尽量不要在 Set 节点里拆解复杂的 JSON。
- 使用 Set 节点时，如果数据源本身就是完整的 JSON 对象，直接引用
{{ $json }}或者对应的键值。 - 如果需要修改，建议使用 Code 节点（Node.js）来处理。在 Code 节点里，你可以用
items[0].json = { ...items[0].json, newField: 'value' }这种方式保留原有结构。 - 在 HTTP Request 的 Body 中，直接引用这个处理后的对象即可。
记住，n8n 很聪明，但前提是你要保持数据结构的清晰，不要人为破坏它的嵌套关系。
坑三：编码与 Content-Type 的“暗战”
第三个坑往往出现在非英文字符传输上。比如你要发送中文参数，或者包含特殊符号的 JSON。
很多时候，HTTP Request 节点默认的 Content-Type 是 application/json，这本身没问题。但如果你的服务器比较老旧，或者配置特殊，它可能要求明确指定字符集，如 application/json; charset=utf-8。
更常见的情况是，n8n 发送的 JSON 字符串中，中文字符被转义成了 Unicode 码（如 u4e2du6587）。虽然这是标准的 JSON 格式，但某些后端语言（如某些版本的 PHP 或 Python 框架）在解析时如果不配置，可能会原样输出这些码。
解决方案：手动设置 Header 与编码
不要依赖默认值，手动去 HTTP Request 节点的 Options -> Header 里添加一行：
- Name:
Content-Type - Value:
application/json; charset=utf-8
此外，如果你发现发送出去的数据结构乱了，检查一下是否在 Query Parameters 或 Body 中错误地使用了 stringify。n8n 会自动处理 JSON 序列化，如果你手动再包一层，就会变成字符串的字符串。
FAQ：N8N 大学答疑时间
Q1：为什么我在 HTTP Request 的 Body 里看不到 JSON 数据预览？
笔者： 这通常是因为你选择了 Form-Data 而不是 JSON 类型。在 HTTP Request 节点的 Body 选项卡下，务必选择 JSON，这样右侧才会出现 JSON 编辑器和参数映射界面。
Q2：如何调试 HTTP Request 发送的原始 JSON？
笔者： 在工作流中插入一个 Debug 节点，或者在 HTTP Request 后面接一个 Function 节点，使用 console.log(JSON.stringify(items[0].json))，然后在 n8n 的 Executions（执行记录）里查看 Logs。这是排查结构问题最快的方法。
Q3：接收方返回的 JSON 格式混乱，n8n 无法自动解析怎么办？
笔者： 如果返回的不是标准 JSON（比如纯文本或 HTML），在 HTTP Request 节点的 Options 中，将 Response Format 手动改为 Text 或 HTML。不要强求 n8n 去解析它，先拿回原始数据，再用 Code 节点提取。
总结与资源
处理 JSON 数据在 n8n 中是家常便饭，但正是这些看似不起眼的细节，决定了工作流的稳定性。核心记住三点：善用 json() 解析函数、保持数据结构完整、手动规范 Header。
如果你在 n8n 的道路上还有其他困惑，欢迎访问 N8N大学 (n8ndx.com)，这里有更多硬核的实战教程和社区交流。避坑，我们是认真的。
