n8n怎么用？从创建节点工作流到连接API的自动化入门指南

先理解n8n的四个基本概念

工作流是一组按连接关系运行的步骤；节点负责接收、转换或发送数据；触发器决定流程何时启动，例如Webhook请求或定时任务；执行记录保存一次运行的状态及相关数据，具体保留内容取决于实例设置。n8n通常以数据项传递JSON字段，后续节点可用表达式读取前面的结果。

搭建一个能验证结果的小流程

准备一个可访问的n8n实例，创建空白工作流，依次连接Webhook、HTTP Request和Respond to Webhook三个节点。本例使用公共回显接口，只发送虚构数据，不填写真实姓名、订单或密钥。

1. 用Webhook接收测试数据

在Webhook节点中把HTTP方法设为POST，路径填写demo-form，并将响应方式设为由Respond to Webhook节点返回。启动测试监听后，复制节点提供的测试URL，用API调试工具向它发送请求：请求头Content-Type为application/json，请求体为{"name":"测试用户","message":"hello"}。

测试URL需要节点处于监听状态。正式接入时，应按实例提供的发布或启用方式使工作流可运行，并改用生产URL；不要把测试地址当作长期入口。

2. 用HTTP Request调用API

添加HTTP Request节点，方法设为POST，URL填写https://httpbin.org/post，启用发送请求体并选择JSON。以字段方式配置name和message，分别使用表达式{{ $json.body.name }}和{{ $json.body.message }}，读取Webhook收到的请求体。

httpbin会回显请求信息。执行后检查输出中的json字段，确认其中包含“测试用户”和“hello”。公共测试接口可能暂时不可用，也不应承载业务数据；这里仅用来观察API请求与响应。

3. 返回结果并完成调试

在Respond to Webhook节点中选择JSON响应，响应体使用表达式{{ $json.json }}，将HTTP Request得到的回显数据返回给调用方。再次监听并发送测试请求，检查调用方响应和各节点输出是否一致。

若字段为空，先查看Webhook输出是否确实存在body.name；若接口报错，检查方法、地址、请求体和响应状态。不要只看最终节点，应沿数据流逐步排查。

凭据、环境变量与入口安全

接入需要认证的API时，优先在n8n的Credentials中配置对应凭据，再由节点引用。不要把令牌直接写进URL、普通字段或共享的工作流文件。导出和分享前仍要检查固定参数与测试数据是否含有秘密。

自托管时，环境变量可用于部署配置，但并非所有环境都允许节点读取环境变量，也不应假定托管服务支持任意注入。按实际部署方式确认可用性，并妥善保存凭据加密密钥、限制配置文件权限。

生产Webhook还应配置适合的认证；接收第三方事件时，按对方规范验证签名。使用HTTPS，对字段类型、长度和必填项做校验，不要因为地址不公开就认为入口安全。

加入分支、重试和错误处理

• 条件分支：在调用API前加入If节点，检查name、message是否存在。无效数据走另一条响应路径，返回明确的错误信息和合适的状态码。
• 重试：可按节点支持的设置启用失败重试。不要对参数错误无限重试；写入订单或发送通知前，应考虑业务唯一编号和幂等机制，防止重复操作。
• 错误处理：可建立包含Error Trigger的错误工作流，并关联到主流程，用于失败通知。若配置节点出错后继续执行，则需单独处理错误输出，不能把失败当成功。
• 执行日志：在执行记录中查看失败节点、输入、输出和错误详情。保存范围与保留期限应兼顾排障和隐私，避免长期留存完整敏感请求。

把示例扩展成实际任务

表单流程可在校验后增加表格写入与通知节点，并分别配置第三方账号权限。内部日报可改用Schedule Trigger，明确时区，再读取RSS或API、整理条目并发送。订单事件则可通过Webhook接收，再调用业务系统接口，但必须补齐签名校验、事件去重与失败补偿。本例不等同于生产方案。

自托管还是托管服务？

自托管可自行安排网络、数据存储和运行环境，但服务器、升级、备份、监控及故障恢复需要自己维护。托管服务减少基础设施维护工作，仍需管理凭据、成员访问和工作流安全。细粒度权限、协作功能与运行额度取决于具体方案；费用也可能包含服务器和第三方API支出，不能理解为所有节点及外部服务都免费。