n8n字段操作指南：变量赋值、类型转换与批量删除（附：保留模式详解）

作者： Dr.n8n 更新时间：2025-12-18 15:00:41 分类：n8n教程

Webhook 数据明明收到了，为什么后续节点却读不到？

上周一位做跨境电商的朋友紧急找我求助：他的订单自动分发流程在 Webhook 接收后突然‘断片’了——数据传进来了，但后续的 Slack 通知和库存扣减节点全都报错‘字段未定义’。他反复检查路径，确认 JSON 结构无误，差点重装整个 n8n 实例。其实，这不是配置错误，而是典型的‘字段生命周期管理失控’——变量没赋好、类型没转对、垃圾没清干净，系统当然罢工。

我在帮某母婴品牌搭建‘客服自动应答 Agent’时，就吃过这个亏：用户上传的图片 URL 是字符串，但图像识别节点要求 Buffer 类型，结果连续三天识别失败，客户投诉暴涨。后来我才明白，n8n 的字段不是‘自来水管’，想用就拧开，而是‘快递包裹’——你得亲手签收、拆箱、分类，甚至改装。

变量赋值：不是“复制粘贴”，而是“契约登记”

很多新手以为，在 n8n 里用 Set 节点给变量赋值，就像 Excel 里 Ctrl+C/V 一样简单。错！n8n 的变量赋值本质是在工作流上下文中注册一个带类型的键值对。如果你不显式声明，系统默认它是“临时工”，随时可能被 GC（Garbage Collection）回收。

// 错误示范：直接引用未声明的路径
{{$node["Webhook"].json["user.email"]}}

// 正确姿势：先用 Set 节点‘登记户口’
Key: userEmail
Value: {{$node["Webhook"].json["user.email"]}}
Type: String

赋值时务必指定类型（String, Number, Boolean, JSON 等），这相当于给变量办“身份证”。后续节点才能凭“证”调用，否则就会触发“未定义字段”报错。我建议所有关键变量都在流程开头集中赋值并加注释，像写合同条款一样严谨。

类型转换：把“橘子”变成“橙汁”的三板斧

n8n 不会自动帮你转换数据类型。字符串 “123” 和数字 123 在它眼里是完全不同的物种。常见翻车现场：API 返回的 price 是字符串 "29.9"，你直接拿去计算折扣，结果得到 NaN（Not a Number）。

解决方案有三个层级：

前端预处理：在 Function 或 Code 节点里用 JavaScript 强制转换：
return { price: parseFloat($input.item.json.price) };
中间件清洗：用 ‘Item Lists’ 节点的 ‘Split Out Items’ + ‘Set’ 组合拳，逐条修正类型。
协议层约束：在 Webhook 或 API 节点设置 ‘Response Data Type’，从源头规范输入格式（比如强制 JSON Schema 校验）。

类比一下：类型转换就像餐厅后厨——生肉（原始数据）不能直接端给客人，必须经过切配（Function）、腌制（Set）、烹调（API 约束）三道工序，才能变成可食用的菜品（合规数据）。

批量删除字段：不是“大扫除”，而是“精准排雷”

当你的数据流携带几十个字段，但下游节点只需要其中 3 个时，冗余字段不仅拖慢性能，更可能触发敏感数据泄露（比如把用户手机号传给了公开日志）。这时候就需要批量删除——但别用蛮力！

n8n 提供两种安全模式：

模式	操作逻辑	适用场景
黑名单模式	列出要删除的字段名，其余全部保留	字段总数少，且明确知道哪些是“垃圾”
白名单模式	列出要保留的字段名，其余全部删除	字段总数多，只需保留关键几个（推荐！）

实操建议：永远优先用白名单模式。就像搬家时只打包必需品，而不是挨个房间扔东西——效率更高，风险更低。