n8n 常用节点实战指南：从 Webhook 到 Code 的「六件套」

作者： Dr.n8n 更新时间：2025-12-02 10:20:51 分类：n8n教程

很多人第一次打开 n8n，看到一整屏节点，心里只有一个问号：到底该从哪个开始连？更糟的是，辛辛苦苦把工作流画完，Webhook 收到了请求，后面的节点却死活拿不到数据；或者明明只是发一批邮件，却被「Items」和「Loop」绕晕。

作为常年帮企业做自动化落地的 Dr. n8n，我可以很负责地说：80% 的业务场景，其实就围绕几类基础节点打转。今天这篇文章，我只讲 6 个：Webhook、Schedule、Loop Over Items、Set、If、Code。如果你把这六件工具玩明白，绝大部分「能落地、能跑稳」的工作流就有了骨架。

这篇文章不讲「所有节点」，只讲那 20% 的高频节点，解决 80% 的真实需求。你可以把它当成 n8n 入门的「核心六件套」说明书。

节点	在系统里的角色
Webhook	外部世界的「门铃」，负责把 HTTP 请求变成工作流入口
Schedule	工作流的「闹钟」，按时间自动触发
Loop Over Items	数据的「传送带」，逐条处理列表中的每一项
Set	数据清洗的「小手术刀」，改字段、删字段、加字段
If	流程里的「岔路口」，基于条件分支
Code	万能的「瑞士军刀」，在节点搞不定时用 JS 自己写

Webhook：给你的工作流装上「门铃」

Webhook 节点允许你通过特定的 URL 接收外部服务的数据，从而触发工作流。你可以把它想象成办公室门口的门铃：有人按了门铃（发送 HTTP 请求），工作流就醒过来干活。

典型场景：

支付成功回调（支付平台调用你的 Webhook）
CRM 新线索创建（SaaS 推送数据给你）
自建系统里，用 POST 请求通知 n8n 执行某个任务

在配置时，我通常会强调这几个点：

用 POST + JSON 作为默认格式，方便后续节点读取
定义好固定的数据结构，避免「今天发这个字段，明天少一个字段」的随机性
上线前用 Postman 或 curl 把请求格式调试到稳定

curl -X POST "https://your-n8n-url/webhook/lead-created" \ -H "Content-Type: application/json" \ -d '{ "name": "Alice", "email": "alice@example.com", "source": "Landing Page A" }'

我见过最多的坑，就是 Webhook 收到的是 application/x-www-form-urlencoded 或乱七八糟的嵌套结构，导致后面节点写表达式时非常痛苦。能统一成 JSON，就尽量统一。

Schedule：用「闹钟」触发例行任务

Schedule 节点的作用很直接：按照设定的时间触发工作流，例如每天早上 9 点发送天气预报、每小时同步一次库存、每晚 23:00 做数据归档。

本质上，它就是一个内置的定时器，不需要你额外部署 crontab 或 CI。

典型用法：

每天 9 点拉取天气 API，然后通过邮件/企业微信/飞书推送
每小时检查一次数据库里的「未处理订单」
每周一早上汇总上周的运营数据报表

当我帮客户设计 Schedule 流程时，会特别提醒：

先在测试环境把 Cron 表达式跑通，再上线生产
涉及外部 API 时，加上限速与重试逻辑，避免高峰期被封 IP
尽量把「重任务」安排在业务低峰时间段

Loop Over Items：批量任务的「传送带」

Loop Over Items 节点用于批量处理数据，例如对客户列表中的每个客户发送个性化邮件。你可以把它理解成：把一大堆物品放到一条传送带上，后面的节点对每个物品执行同样的动作。

常见场景：

对 CSV 中的每一行数据执行相同的 API 调用
对订单列表中的每个订单生成发票
对用户列表发送批量通知，但内容稍有个性化

这里有一个非常典型的工作流组合：

用 HTTP Request 或 Database 节点拿到一批数据（比如 100 个客户）
通过 Loop Over Items 把 100 条记录拆成「逐条处理」
在 Loop 里用 Set/Code/If 等节点做个性化逻辑

我帮一家做 B2B SaaS 的公司做过一条批量续费提醒流，刚开始他们用 Code 节点自己 forEach，结果一不小心一次性打出去几千封邮件。改成 Loop Over Items 后，再配合并发控制，整个任务就稳多了。

Set：给数据做「小手术」

Set 节点用于修改数据字段，例如重命名字段或添加新的字段。它不负责从外部获取数据，而是对当前 items 做「局部调整」。

典型用途：

重命名字段：从 first_name 改成 firstName
新增字段：根据现有字段拼接出 fullName 或 displayTitle
删除多余字段：只保留后续节点需要的少量字段，减小负担

例如，我们可以在 Set 节点中设置一个新字段 fullName：

fullName = {{$json["firstName"] + " " + $json["lastName"]}}

我个人的习惯是：每当数据从「一个系统」进入「另一个系统」时，都会加一个 Set 节点，把字段名和结构统一一遍，相当于做一次「中台格式」。这样后续工作流维护成本会低很多。

If：让工作流在岔路口做出选择

If 节点根据条件判断执行不同的操作，例如如果今天是星期天就发送提醒，或者如果订单金额大于 5000 就走人工审核流程。

你可以把 If 看成流程图里的菱形判断框：

条件为真（True）：走一条线
条件为假（False）：走另一条线

常见的条件表达式示例：

判断星期几：

{{$now().format("d") === "0"}} // 是否是周日，具体写法可按实际表达式支持调整

判断订单金额：

{{$json["amount"] > 5000}}

在实际项目里，我经常用 If 把流程拆成「正常路径」和「异常路径」两类。比如调用外部 API 的时候，如果返回状态码不是 200，就走另一条线，记录日志并通知运维，而不是直接让工作流「悄无声息地失败」。

Code：在节点搞不定时，掏出瑞士军刀

Code 节点是整个 n8n 里的兜底选项。当前面五个节点都搞不定你的需求时，通常就是 Code 节点出场的时候了。

它允许你写 JavaScript 来操作当前 items，比如：

复杂的数据转换（嵌套 JSON 重构、批量聚合）
自定义算法：打分、排序、权重计算
对多个字段做逻辑运算，生成新字段

一个典型的 Code 节点示例：给每个用户生成一个简单的标签字段。

// items 是一个数组，每个元素代表前面节点的一条记录 // Code 节点需要返回同样结构的 items 数组 return items.map(item => { const data = item.json; // 根据消费金额生成 VIP 等级 let level = "normal"; if (data.totalSpent > 10000) { level = "vip"; } else if (data.totalSpent > 5000) { level = "plus"; } // 写回 json return { json: { ...data, level, displayName: `${data.firstName} ${data.lastName || ""}`.trim() } }; });