n8n 中文教程：HTTP 请求 (HTTP Request)

大家好，我是翔宇。在日常使用 n8n 构建自动化工作流的过程中，我们经常会遇到这样的场景：你发现了一个非常有用的在线服务，它提供了 API 接口，可以让你通过程序化的方式获取数据或执行操作。比如，你可能想将一个在线问卷收集到的用户信息，自动同步到一个内部的项目管理系统；或者，你需要根据一个实时天气 API 返回的数据，来决定是否自动给团队发送一条提醒信息。

然而，当你兴致勃勃地打开 n8n，准备添加节点时，却发现 n8n 并没有为这个特定的服务提供现成的、开箱即用的节点。这时候，特别是对于没有编程基础的朋友来说，可能会感到有些沮丧和无助：难道没有代码能力，就无法将这个服务接入到我的自动化流程中了吗？

别担心，这正是 n8n 中一个极其强大的核心节点——HTTP 请求 (HTTP Request) 发挥作用的时候。你可以把它想象成 n8n 工作流中的一把“瑞士军刀”或者一把“万能钥匙” 。无论对方是什么服务，只要它提供了基于 HTTP 协议的 API 接口（目前绝大多数 Web API 都基于此），HTTP 请求节点就能与它进行通信。这意味着，即使 n8n 没有为某个服务开发专门的节点，你依然可以通过配置 HTTP 请求节点来调用它的 API，实现数据的获取和操作。

这个节点的核心价值在于其通用性和灵活性 。它打破了 n8n 内置集成数量的限制，让你能够连接几乎“万物”；同时，它提供了丰富的配置选项，允许你精确控制请求的每一个细节，满足各种 API 的复杂要求。对于我们这些追求高效自动化的用户，尤其是零代码基础的朋友们来说，掌握 HTTP 请求节点，就等于解锁了 n8n 的绝大部分潜力，能够突破预置节点的局限，构建出真正符合个性化需求的、强大的自动化工作流。可以说，不掌握这个节点，你的 n8n 之旅是不完整的。

目录隐藏

1 节点概览

2 参数与配置 (深度)

3 数据映射与表达式 (重点)

4 应用场景

5 常见报错及解决方案 (实用)

6 注意事项

教程内容简介

在本篇深度教程中，我将结合自己(“翔宇工作流”作者翔宇)在实战中积累的经验和踩过的坑，用最通俗易懂的语言，搭配恰当的比喻，手把手带你彻底搞懂 HTTP 请求节点的方方面面。我们将一起探索：

节点概览: 它的功能定位、核心价值，以及它如何接收数据 (Input) 和返回结果 (Output)。
参数与配置: 详细拆解节点的每一个配置项，从请求方法 (Method)、URL、认证 (Authentication) 到请求头 (Headers)、请求体 (Body) 以及各种高级选项 (Options) 和设置 (Settings)，并分享我在不同场景下的实战理解和推荐配置。
数据映射与表达式: 这是节点的灵魂所在。我们将学习如何使用 n8n 表达式动态构建请求，将上游节点的数据灵活运用到请求的各个部分，并剖析常见的映射技巧和易错点。
应用场景: 展示一些我常用的 HTTP 请求节点实战场景，给你启发。
常见报错及解决方案: 汇总新手最容易遇到的错误提示，分析原因，提供清晰的排错思路、调试方法和日志定位技巧。
注意事项: 总结使用该节点时需要注意的关键事项，以及关于节点版本兼容性的一些说明。

准备好了吗？让我们一起开启 HTTP 请求节点的探索之旅，解锁 n8n 的无限可能！

节点概览

节点功能定位与核心价值

功能定位:

HTTP 请求节点是 n8n 中用于与外部 Web 服务进行底层通信的核心基础节点。你可以把它理解为 n8n 内置的一个强大的、可配置的“网络浏览器”或“API 客户端”。它的主要任务就是根据你的配置，向指定的网络地址 (URL) 发送一个 HTTP 请求，并接收服务器返回的响应。它是实现与各种 Web API，特别是遵循 RESTful 风格设计的 API 进行交互的通用工具。

核心价值 (翔宇理解):

通用性: 这是 HTTP 请求节点最核心的价值。互联网上存在着成千上万的 Web 服务和应用程序，它们中很多都提供了 API 接口。虽然 n8n 已经内置了对数百种流行服务的集成节点，但这相比于庞大的互联网服务生态来说仍然是有限的。HTTP 请求节点则弥补了这一差距，它允许你连接到任何一个提供了标准 HTTP API 的服务，无论 n8n 是否为其制作了专用节点。对我来说，这意味着理论上你可以用 n8n 连接“万物”，极大地扩展了自动化的边界。
灵活性: 与那些为了简化操作而封装好的专用节点不同，HTTP 请求节点暴露了 HTTP 通信的几乎所有可配置细节。你可以精确地控制请求的方法 (GET, POST 等)、目标 URL、身份认证方式、请求头 (Headers)、请求体 (Body) 的内容和格式，以及超时、重试、代理等各种网络行为。这种灵活性使得它能够应对各种“刁钻”或特殊的 API 要求。
自动化扩展的基石: 很多稍微复杂一些的自动化场景，都离不开 HTTP 请求节点。比如，你需要将多个系统的数据进行整合，或者当某个系统发生事件时，需要调用另一个系统的 API 来触发特定操作，或者你需要根据 API 返回的数据动态地决定工作流的下一步走向等等。在这些场景下，HTTP 请求节点扮演着数据流通和系统交互的关键桥梁作用。我认为，不掌握这个节点，n8n 的能力将受到很大限制。

与专用节点的对比:

翔宇在这里想强调一下 HTTP 请求节点和那些专用节点（比如 Google Sheets 节点、Slack 节点）的区别。专用节点通常针对特定的服务进行了优化，隐藏了底层 API 的复杂性，提供了更简洁、更友好的配置界面。例如，使用 Google Sheets 节点添加一行数据，你只需要选择表格、填写列名和对应的值即可，无需关心底层的 API 调用细节。

然而，这种简化也意味着功能的局限性。有时，专用节点可能没有提供你需要的某个特定 API 操作，或者它的配置选项无法满足你的特殊需求。这时，HTTP 请求节点就派上用场了。你可以查阅该服务的 API 文档，然后使用 HTTP 请求节点直接调用对应的 API 接口，实现专用节点无法完成的功能。

简单来说：

专用节点: 方便、快捷，适用于标准、常见的操作。
HTTP 请求节点: 灵活、通用、强大，适用于专用节点不支持的操作、连接未集成的服务或需要精细控制请求细节的场景。

对于初学者，可以先尝试使用专用节点。但要想真正发挥 n8n 的威力，实现更广泛、更深入的自动化，学习和掌握 HTTP 请求节点是必经之路。

输入（Input）与输出（Output）数据结构

要有效地使用 HTTP 请求节点，首先需要理解 n8n 的基本数据流转方式以及该节点的输入输出特性。

n8n 数据结构基础:

在 n8n 中，数据在节点之间传递的基本格式是一个数组 (Array)，这个数组里面包含了一个或多个 JSON 对象 (Object) 。每个 JSON 对象通常被称为一个项目 (Item)。标准的结构看起来像这样：

JSON

[
  {
    "json": {
      "字段名1": "值1",
      "字段名2": "值2"
    },
    "binary": { // 可选，用于存储二进制数据，如文件
      "binaryPropertyName": {... }
    }
  },
  {
    "json": {
      "字段名1": "另一个值1",
      "字段名2": "另一个值2"
    }
  }
  //... 可能有更多 Item
]

你需要记住的关键点是：n8n 的工作流本质上是在处理这一系列的 Item。大多数节点（包括 HTTP 请求节点）默认情况下会对输入的每一个 Item 执行一次其主要操作 。这是 n8n 能够轻松处理批量数据的核心机制。

输入 (Input):

HTTP 请求节点接收来自其上游节点的标准 n8n 数据结构（即 Item 数组）。这些传入的 Item 数据通常用于动态地构建 HTTP 请求的各个部分。例如：

如果上游节点是一个 Google Sheets 节点，读取了一列用户 ID，那么每个 Item 的 json 对象里可能包含一个 userId 字段。你可以用这个 userId 来动态构建请求的 URL，比如 https://api.example.com/users/{{ $json.userId }}，从而为每个用户 ID 发送一次请求以获取该用户的详细信息。
如果上游节点是一个 Webhook 节点，接收了一个在线表单的提交数据，那么 Item 的 json 对象里可能包含 name, email 等字段。你可以用这些字段来构建一个 POST 请求的 Body，将数据提交到另一个系统的 API。

翔宇提示: 在配置 HTTP 请求节点之前，务必先运行它的上游节点，并仔细查看其输出 (Output Data)。了解清楚上游节点输出了多少个 Item，以及每个 Item 的 json 对象里具体有哪些字段和对应的值，这对于后续正确使用表达式来引用这些数据至关重要。

输出 (Output):

HTTP 请求节点执行完 API 调用后，会将其结果作为新的 Item 数组输出给下游节点。输出的具体结构取决于你的配置：

默认情况 (只输出 Body):
- 默认情况下，节点只输出 API 响应的主体内容 (Response Body) 。
- n8n 会尝试根据服务器返回的响应头中的 Content-Type 字段来自动解析 Body。例如，如果 Content-Type 是 application/json，n8n 会尝试将 Body 解析为 JSON 对象；如果是 text/plain，则解析为文本。
- 输出结构示例 (假设 API 返回 JSON): [ { "json": { "api返回的键": "api返回的值",... } } ]
- 如果原始输入有多个 Item，并且节点对每个 Item 都成功发起了请求并收到了响应，那么输出也会包含对应数量的 Item，每个 Item 的 json 字段包含了对应请求的响应 Body。
包含 Headers 和 Status (更完整的输出):
- 在很多情况下，我们不仅关心响应的 Body，还需要知道响应的状态码 (比如 200 表示成功，404 表示未找到) 或响应头中的某些信息 (比如分页信息、认证令牌等)。
- 你可以通过点击节点配置界面下方的 Add Option，选择 Response，然后勾选 Include Response Headers and Status 选项来实现。
- 启用此选项后，输出的每个 Item 的 json 对象会变成一个包含多个字段的结构：
  - body: 原始的响应 Body (n8n 仍会尝试自动解析)。
  - headers: 一个包含所有响应头的 JSON 对象。
  - statusCode: HTTP 状态码 (数字类型，如 200, 404, 500)。
  - statusMessage: HTTP 状态消息 (字符串类型，如 “OK”, “Not Found”)。
- 输出结构示例: JSON[ { "json": { "body": { "api返回的键": "api返回的值",... }, "headers": { "content-type": "application/json", "x-ratelimit-remaining": "99",... }, "statusCode": 200, "statusMessage": "OK" } } ]
- 翔宇强烈建议: 在调试 API 或需要根据状态码/响应头做后续判断时，一定要开启这个选项！
二进制数据输出:
- 如果 API 调用返回的是一个文件（如图、PDF）或其他二进制数据，并且你在 Response 选项中将 Response Format 设置为了 File，那么输出 Item 的 json 对象旁边，通常会多出一个 binary 对象。
- binary 对象内部会包含一个由你在 Put Output in Field 字段中指定的名称（例如 responseFile）的属性，这个属性的值是一个描述该二进制数据的对象，包含了文件名、MIME 类型等信息，并指向 n8n 内部存储的实际二进制数据。下游的文件处理节点（如 Write Binary File）可以直接使用这个 binary 数据。

翔宇强调: 理解 HTTP 请求节点的输出结构，是使用下游节点（如 Set, IF, Code, 或其他 API 节点）来处理 API 响应数据的基础。务必根据你的需求，合理配置 Response 选项，并在配置完成后实际运行一次节点，仔细观察 Output Data 面板中的输出结果，确认其结构和内容符合你的预期。

一个重要的潜在问题: 正因为 n8n 默认会对每个输入的 Item 执行一次操作，如果你不注意上游节点的输出数量，可能会在不经意间向目标 API 发送大量请求。例如，如果上游节点输出了 1000 个 Item，HTTP 请求节点默认就会尝试发送 1000 次 API 调用。而大多数 API 都有速率限制 (Rate Limit) ，短时间内收到过多请求会返回 429 Too Many Requests 错误。因此，在配置 HTTP 请求节点时，不仅要关注单个 Item 的数据，还要关注 Item 的数量，并结合后面会讲到的 Batching (批处理)、Retry On Fail (失败时重试) 或 Execute Once (执行一次) 等设置来主动控制请求的频率和次数，这是避免 429 错误的关键一步。

参数与配置 (深度)

现在，让我们深入 HTTP 请求节点的内部，逐一拆解它的各项参数和配置。掌握这些配置是驯服这把“瑞士军刀”的关键。

Method (方法)

含义: Method 定义了你想要对目标资源执行的操作类型或意图。它是 HTTP 协议的核心概念之一。我们可以用一个简单的比喻来理解：
- GET: 像去图书馆查阅某本书的信息（获取资源）。
- POST: 像向图书馆提交一份新书的入馆申请（创建资源或提交数据）。
- PUT: 像用一本新书替换掉图书馆里的一本旧书（替换整个资源）。
- PATCH: 像给图书馆里的某本书打个补丁，修正其中的几个错字（部分更新资源）。
- DELETE: 像把图书馆的某本书彻底销毁（删除资源）。
可选值: n8n 的 HTTP 请求节点提供了以下标准的 HTTP 方法供选择：
- GET: 获取资源。这是最常用的方法之一，通常用于读取数据。请求参数一般附加在 URL 后面（Query Parameters）。
- POST: 创建资源或提交数据进行处理。数据通常放在请求体 (Body) 中发送给服务器。
- PUT: 替换服务器上的资源，或者根据指定的 URI 创建一个新资源。数据也在请求体中。PUT 请求通常被认为是幂等的，意味着执行一次和执行多次的效果应该是一样的。
- PATCH: 对资源进行部分修改。数据在请求体中，只包含需要更改的字段。
- DELETE: 删除指定的资源。
- HEAD: 类似于 GET，但服务器只返回响应头 (Headers)，不返回响应体 (Body)。常用于检查资源是否存在、获取元信息（如最后修改时间）或检查链接有效性，而无需下载整个内容。
- OPTIONS: 获取目标资源所支持的通信选项，例如服务器允许对该资源使用哪些 HTTP 方法 (GET, POST 等) 或支持哪些自定义的请求头。
翔宇实战选择建议:
- 永远参考 API 文档！ 这是选择 Method 的黄金法则。任何一个设计良好的 API 都会在其文档中明确指出，调用某个特定的功能或操作需要使用哪种 HTTP Method。绝对不要凭感觉猜测。
- 在实际应用中，GET (获取数据) 和 POST (提交/创建数据) 是最最常用的两种方法。
- 当你需要更新数据时，要特别注意 API 文档是要求使用 PUT 还是 PATCH。PUT 通常要求你提供完整的资源表示，而 PATCH 只需提供要修改的部分。如果 API 支持 PATCH，通常更高效。
- 新手易混淆点: 不要随意选择 Method。如果你用 GET 方法去尝试创建一个资源，或者用 POST 方法去尝试删除一个资源（除非 API 特殊设计），服务器很可能会返回错误，比如 405 Method Not Allowed。

URL (链接)

含义: URL (Uniform Resource Locator) 是你要与之交互的 API 资源的具体网络地址。它就像你要寄达的信件地址，必须精确无误，才能找到正确的“收件人”（服务器上的资源）。
构成: 一个典型的 API URL 通常由以下几部分组成：
- 协议 (Protocol): 指明通信方式，通常是 http 或更安全的 https。
- 主机名 (Hostname): API 服务器的域名或 IP 地址，例如 api.example.com。
- 路径 (Path): 指向服务器上具体的资源或功能，例如 /v1/users/123 或 /search。
- 查询参数 (Query Parameters): 可选部分，跟在 ? 后面，用于传递额外的信息，如筛选条件、分页参数等，格式为 key=value，多个参数用 & 连接，例如 ?status=active&limit=10。
配置: 在 HTTP 请求节点的 “URL” 输入框中，你需要填写完整的 API 访问地址。
动态构建 URL (非常常用):
- 在自动化场景中，URL 的某些部分往往不是固定的，而是需要根据上游节点的数据动态生成。这时就需要用到 n8n 的表达式，将表达式包裹在双花括号 {{ }} 中嵌入到 URL 字符串里。
- 示例 1 (动态路径参数): 假设上游节点输出的 Item 包含一个 userId 字段，你想获取该用户的详细信息，URL 可以这样写： https://api.example.com/users/{{ $json.userId }}
- 示例 2 (动态查询参数): 假设上游节点输出一个 searchTerm 字段，你想用它来搜索，URL 可以这样写： https://api.example.com/search?query={{ $json.searchTerm }}
- 示例 3 (混合动态):https://{{ $env.API_HOST }}/api/v2/items/{{ $json.itemId }}?include_details={{ $node.json.includeDetails }} 这里同时使用了环境变量、当前 Item 的 itemId 和来自名为 “Settings Node” 节点的数据。
翔宇经验:
- 仔细，再仔细！ URL 中的任何一个拼写错误，多一个或少一个斜杠 /，都可能导致请求失败，最常见的就是返回 404 Not Found 错误。务必从 API 文档中复制粘贴，并仔细核对。
- 区分 Base URL 和 Endpoint: API 文档通常会提供一个基础 URL (Base URL)，例如 https://api.example.com/v1，然后针对不同的功能提供具体的端点 (Endpoint)，例如 /users 或 /orders/{orderId}。你需要将它们正确地拼接起来。
- 检查动态数据: 当你使用表达式动态构建 URL 时，一定要确保表达式引用的字段（如 {{ $json.userId }} 中的 userId）在上游节点的输出中确实存在，并且其值是有效的。如果字段不存在或值为 null，可能会生成一个无效的 URL。你可以先运行上游节点，查看输出数据确认。常用的引用方式包括 $json.fieldName (引用当前 Item 的字段) 或 $node["节点名称"].json["字段名"] (引用其他节点的数据) 。
- 特殊字符处理: 如果你的动态参数值中可能包含特殊字符（例如空格、&、=、? 等），n8n 的表达式通常会自动进行 URL 编码（将特殊字符转换为 %xx 的形式），以确保 URL 的有效性。但如果你手动拼接非常复杂的查询字符串，可能需要留意编码问题。大多数情况下，让 n8n 自动处理即可。

Authentication (认证)

含义: 认证是向 API 服务器证明“你是谁”以及“你是否有权访问”其资源的过程。它就像进入一个需要门禁的小区，你需要刷卡或输入密码来证明你的身份和权限。
重要性: 绝大多数提供有价值数据或功能的 API 都需要某种形式的认证。如果你没有提供正确的认证信息，API 服务器通常会拒绝你的请求，返回 401 Unauthorized (未授权，通常表示缺少或无效的凭据) 或 403 Forbidden (禁止访问，通常表示凭据有效但权限不足) 的错误。这是新手在使用 HTTP 请求节点时最常遇到的“拦路虎”之一。
配置方式: n8n 提供了两种主要的认证配置方式：
- 1. Predefined Credential Type (预定义凭据类型):
  - 适用情况: 当你要连接的服务是 n8n 已经内置支持的集成时（无论是官方节点还是社区节点），例如 Google Services (Sheets, Drive, Calendar), AWS, HubSpot, Slack, GitHub 等等。
  - 优点: 这是最推荐的方式，因为它极大地简化了认证配置过程。你只需要在 n8n 主界面的 “Credentials” 菜单中，按照引导添加一次你的账户凭据（比如登录 Google 账号授权 n8n 访问），n8n 就会安全地存储这些信息，并自动处理复杂的认证流程（例如 OAuth 2.0 的令牌获取和刷新）。
  - 配置步骤:
    1. 先去 n8n 左侧菜单的 “Credentials” 添加对应服务的凭据。
    2. 在 HTTP 请求节点的 “Authentication” 部分，从 “Credential Type” 下拉列表中选择你要连接的服务名称（例如 “Google” 或 “HubSpot API”）。
    3. 在下方的 “Credential Name” (或类似名称) 下拉列表中，选择你刚才添加好的凭据。
  - 翔宇建议: 只要目标服务出现在 “Credential Type” 的列表中，就优先使用这种方式。它不仅方便，而且更安全，因为 n8n 会帮你管理敏感的令牌信息。
- 2. Generic Credential Type (通用凭据类型):
  - 适用情况: 当你要连接的 API 服务 n8n 没有内置支持，或者你需要更精细地控制认证的细节时。
  - 常见类型详解: n8n 提供了多种通用的认证机制，你需要根据目标 API 文档的要求来选择并配置：
    - None: 无需认证。适用于完全公开的 API。
    - Basic Auth: 使用用户名 (Username) 和密码 (Password) 进行认证。配置简单，只需填写用户名和密码。但这种方式安全性较低，因为用户名和密码通常是以 Base64 编码后放在请求头中发送，容易被截获和解码。仅在 API 只支持此方式且连接是 HTTPS 时谨慎使用。
    - Header Auth: 这是非常常用的一种认证方式。它通过在 HTTP 请求的头部 (Header) 中添加特定的认证信息来工作。常见的形式有：
      - API Key: 很多 API 会提供一个唯一的字符串（API Key 或 Secret Key）作为凭证。你需要根据 API 文档，在 “Name” 字段填入指定的 Header 名称（例如 X-API-Key, Authorization, api-key 等），在 “Value” 字段填入你的 API Key。
      - Bearer Token: 这是 OAuth 2.0 等现代认证方案中常用的方式。API 会先通过其他方式给你一个访问令牌 (Access Token)，然后你在每次请求时，需要在 “Name” 字段填入 Authorization，在 “Value” 字段填入 Bearer <你的访问令牌>（注意：Bearer 和令牌之间通常有一个空格！）。
      - 配置: 选择 “Header Auth”，然后点击 “Add Header Auth Field”，输入 Header 的 “Name” 和 “Value”。
      - 翔宇踩坑: Header 的 “Name” 和 “Value” 必须严格按照 API 文档的要求填写，包括大小写、特殊字符、前缀（如 Bearer）等，一点都不能错。否则，服务器可能无法识别你的凭证。
      - 动态 Header Auth 值: 如果你的 API Key 或 Token 是动态生成的（例如，由上一个节点获取），你可以在 “Value” 字段中使用表达式来引用它，例如 {{ $json.apiToken }} 或 Bearer {{ $node.json.access_token }} 。
    - OAuth1 API / OAuth2 API: 这两种是用于更复杂授权流程的标准协议，通常涉及用户重定向授权、客户端 ID 和密钥、获取授权码、交换访问令牌和刷新令牌等步骤。配置相对复杂，需要你仔细阅读 API 文档，并在 n8n 的 Credential 配置界面中填写 Consumer Key, Consumer Secret, Access Token URL, Authorization URL, Scope 等一系列参数。n8n 会尽可能简化这个流程，但理解 OAuth 的基本概念会很有帮助。
    - Query Auth: 将认证信息（如 API Key 或 Token）作为查询参数直接附加在 URL 的末尾，例如 https://api.example.com/data?apiKey=YOUR_KEY。这种方式相对不安全，因为敏感信息会直接暴露在 URL 中，容易被记录在日志或浏览器历史里。除非 API 强制要求，否则不推荐。
    - Digest Auth: 一种比 Basic Auth 更安全的用户名/密码认证方式，涉及到摘要计算，可以防止密码在网络上明文传输。如果 API 文档指定使用 Digest Auth，你需要选择此项并填写用户名和密码。
    - Custom Auth: 用于极其特殊的、非标准的认证机制，极少使用。
  - 翔宇安全建议:
    - 切勿硬编码敏感信息！ 这是一个非常重要的安全原则。永远不要将你的 API Key、密码、Secret Key 或完整的 Bearer Token 直接写在 HTTP 请求节点的 URL、Header Value 或 Body 参数里。这样做会让你的敏感凭据暴露在 n8n 的工作流定义中，甚至可能出现在执行日志里，带来极大的安全风险。
    - 始终使用 n8n 的 Credentials 系统！ 无论是 Predefined 还是 Generic 类型（如 Header Auth, Basic Auth, OAuth2 等），都应该先在 n8n 的 Credentials 菜单中创建对应的凭据项，将敏感信息保存在那里。n8n 会对存储的凭据进行加密。然后在 HTTP 请求节点中引用你创建的凭据名称。这样既安全又方便复用。
    - 动态 Token 的处理: 如果你使用 Header Auth，并且 Token 是动态从上游节点获取的，也要注意这个 Token 在传递过程中的安全性。尽量避免将完整的 Token 打印到日志中。
    - 警惕潜在 Bug: 社区中有用户报告过，在某些旧版本或特定情况下，使用 Predefined Credentials 可能没有正确地将 Authorization Header 添加到请求中，导致认证失败。虽然这可能是特定情况下的 Bug，但如果你在使用 Predefined Credentials 时反复遇到 401/403 错误，并且确认凭据本身无误，可以尝试改用 Generic Header Auth 并手动配置 Header 作为一种排查手段。
总结: 身份认证是调用 API 的第一道关卡，也是新手最容易出错的地方之一。返回 401 错误通常意味着你的凭据有问题（缺失、格式错误、无效或过期），而 403 错误则更多地指向权限问题（凭据有效，但被禁止执行该操作）。仔细阅读 API 文档，选择正确的认证方式，并通过 n8n 的 Credentials 系统安全地管理你的敏感信息，是成功配置认证的关键。

Send Query Parameters (发送查询参数)

含义: 查询参数是附加在 URL 末尾，用于向服务器传递额外信息的一种方式，通常用于 GET 请求中对返回结果进行筛选 (Filtering)、排序 (Sorting) 或分页 (Pagination) 。你可以把它想象成你去图书馆查书时，告诉图书管理员：“我要找关于‘人工智能’的书（筛选），并且请按照‘出版年份’倒序排列（排序），每页显示 20 本（分页）”。这些附加条件就是查询参数。它们通常以 ? 开始，参数之间用 & 分隔，格式为 key=value，例如 ?category=AI&sort=year_desc&limit=20。
配置方式: 在 HTTP 请求节点中，如果你需要发送查询参数，首先要打开 “Send Query Parameters” 的开关。然后有两种方式来定义这些参数：
- 1. Using Fields Below (使用下方字段):
  - 这是最直观的方式。点击 “Add Parameter” 按钮，会添加一行，让你输入参数的 Name (名称) 和 Value (值) 。
  - 你可以添加多行来定义多个参数。
  - 参数的 Value 可以是固定的静态值（直接输入），也可以是动态的，通过使用表达式 {{ }} 来引用上游节点的数据。
  - 示例:
    - 添加一行：Name=status, Value=active
    - 再添加一行：Name=userId, Value={{ $json.id }} (假设上游 Item 中有 id 字段)
    - n8n 会自动将这些参数组合并附加到 URL 末尾，生成类似 ?status=active&userId=123 的效果。
- 2. Using JSON (使用 JSON):
  - 这种方式允许你在一个 JSON 对象中定义所有的查询参数。JSON 对象的键 (Key) 就是参数的 Name，值 (Value) 就是参数的 Value。
  - 示例:JSON{ "status": "active", "limit": {{ $json.pageSize }}, "sort_order": "desc" } 这里 status 和 sort_order 是静态值，而 limit 的值是动态从上游 Item 的 pageSize 字段获取的。
  - 翔宇提示: 当你需要定义的查询参数比较多，或者参数本身有嵌套结构（虽然不常见于查询参数），或者你更习惯用 JSON 来组织数据时，使用这种方式可能更清晰、更方便管理。
Array Format in Query Parameters (选项):
- 这是一个重要的选项，位于 “Options” 部分（需要点击 “Add Option” 添加）。它用来控制当你的查询参数值是一个数组时，n8n 应该如何将其格式化到 URL 中。不同的 API 可能有不同的要求。
- 常见格式:
  - No Brackets (默认): filter=A&filter=B&filter=C
  - Brackets Only: filter=A&filter=B&filter=C
  - Brackets with Indices: filter=A&filter=B&filter=C
  - Comma Separated: filter=A,B,C
- 如何选择: 必须查阅目标 API 的文档，看它要求数组参数以哪种格式传递。选错了格式，API 可能无法正确解析你的参数。
翔宇常用场景:
- 数据筛选: 根据特定条件过滤返回结果，例如 ?status=completed, ?product_category=electronics, ?name=John。
- 分页: 控制返回数据在哪一页以及每页有多少条记录，例如 ?page=2&limit=50 或 ?offset=100&count=20 。这是处理大量数据时必须使用的功能。
- 排序: 指定返回结果按照哪个字段以及升序 (asc) 还是降序 (desc) 排列，例如 ?sort_by=createdAt&order=desc。
- 动态查询: 根据用户的输入、或其他节点的计算结果来动态构建查询条件，实现灵活的数据检索。
翔宇易错点:
- 大小写敏感: 查询参数的 Name (名称) 通常是大小写敏感的，必须与 API 文档中定义的完全一致。userId 和 userid 可能会被 API 视为不同的参数。
- 值的类型: 确保传递的值类型符合 API 要求（例如，需要数字的地方不要传字符串 “123”）。表达式可能需要进行类型转换。
- URL 编码: 当参数值包含特殊字符（如空格、&、=、+、# 等）时，它们需要被正确地进行 URL 编码才能放入 URL 中。n8n 的表达式通常会自动处理编码，但如果你在 “Using Single Field” 模式下手动构建包含动态内容的查询字符串，需要特别注意编码问题。使用 “Using Fields Below” 或 “Using JSON” 模式通常更安全。
- 忘记 “?” 和 “&”: 使用 “Using Fields Below” 或 “Using JSON” 时，n8n 会自动添加 ? 和 &。但如果你直接在 URL 字段中手动拼接查询参数，别忘了这些连接符。

Send Headers (发送请求头)

含义: HTTP Headers (请求头) 是附加在 HTTP 请求中的一系列键值对 (Key-Value Pairs)，用于传递关于请求本身的元信息 (Metadata) 。它们不像 URL 或 Body 那样直接定义要操作的资源或数据，而是提供一些上下文信息，例如：你是谁（认证信息）、你发送的数据是什么格式、你期望接收什么格式的响应、你使用的客户端类型等等。类比于寄信时，信封上除了地址（URL）和信件内容（Body）之外，还写了发件人信息、内容类型说明（如“内含照片，请勿折叠”）、期望的回信方式等。
常见的 Headers 及其作用:
- Content-Type: 这个 Header 极其重要，尤其是在发送请求体 (Body) 的时候（如 POST, PUT, PATCH 请求）。它明确告知服务器，你发送的 Body 数据是什么格式的。常见的值有：
  - application/json: 表示 Body 是 JSON 格式。
  - application/x-www-form-urlencoded: 表示 Body 是 URL 编码的表单数据。
  - multipart/form-data: 表示 Body 是包含文件上传的表单数据。
  - text/plain: 表示 Body 是纯文本。
  - text/xml: 表示 Body 是 XML 格式。
  - 如果 Content-Type 设置错误，服务器可能无法正确解析你的请求体，导致请求失败或数据处理错误。
- Authorization: 用于传递身份认证凭据。具体的值取决于认证机制，常见的有：
  - Basic <base64编码的username:password> (用于 Basic Auth)
  - Bearer <你的访问令牌> (用于 OAuth 2.0 或基于 Token 的认证)
  - ApiKey <你的API密钥> (某些 API 可能使用这种自定义模式)
- Accept: 这个 Header 告知服务器，你的客户端（n8n）期望接收什么格式的响应数据。常见的值有：
  - application/json: 表示你希望服务器返回 JSON 格式的数据。
  - application/xml: 表示你希望服务器返回 XML 格式的数据。
  - */*: 表示你可以接受任何格式的响应。
  - 服务器会根据这个 Header (如果提供了) 以及它自身的能力，来决定返回什么格式的数据。如果服务器不支持你期望的格式，它可能会返回默认格式或错误。
- User-Agent: 用于标识发送请求的客户端软件及其版本。n8n 默认会发送类似 axios/0.21.4 (或其他版本) 的 User-Agent。有些 API 服务器可能会根据 User-Agent 来判断请求来源，甚至进行限制或返回不同的内容。在少数情况下，你可能需要根据 API 文档的要求，修改这个 Header 来模拟浏览器或其他客户端。
- 自定义 Headers: API 可能要求你发送一些它们自己定义的 Header，通常以 X- 开头，例如 X-API-Key, X-Request-ID, X-Tenant-ID 等。这些都需要根据 API 文档来添加。
配置方式: 在 HTTP 请求节点中，打开 “Send Headers” 开关后，同样有两种方式定义 Headers：
- 1. Using Fields Below (使用下方字段):
  - 点击 “Add Parameter”，输入 Header 的 Name (名称) 和 Value (值) 。
  - 可以添加多行来定义多个 Header。
  - Header 的 Value 可以使用表达式 {{ }} 来动态生成。
- 2. Using JSON (使用 JSON):
  - 在一个 JSON 对象中定义所有的 Header 。JSON 对象的键是 Header Name，值是 Header Value。
  - 翔宇提示 (重要): 如果你想在 JSON 模式下使用表达式来动态设置 Header 的值，你需要将整个 JSON 对象包裹在表达式 {{ }} 中。例如： JSON{{ { "Authorization": "Bearer " + $json.accessToken, "Content-Type": "application/json", "X-Request-ID": $runIndex } }} 注意，这里不是 {"Authorization": "Bearer {{ $json.accessToken }}"}，而是将整个 {...} 放在 {{ }} 内部。
动态 Headers 构建:
- 场景: 最常见的场景是 Authorization Header 中的 API Key 或 Bearer Token 需要从上游节点（例如，一个获取 Token 的 HTTP 请求节点，或者一个存储凭据的节点）动态获取。
- 示例 (Using Fields Below):
  - Name: Authorization
  - Value: Bearer {{ $node.json.access_token }}
- 示例 (Using JSON): (如上所示)
翔宇实战心得:
- Content-Type 是祸根之一: 当你发送 Body 数据（特别是 JSON 或 Form-Data）时，忘记设置或设置错误的 Content-Type Header 是导致请求失败的常见原因。务必根据你选择的 “Body Content Type” 来设置正确的 Content-Type Header。
- API 文档是唯一真理: 再次强调，你需要发送哪些 Header，以及它们的 Name 和 Value 应该是什么，完全取决于目标 API 的文档。不要猜测，仔细阅读文档。
- 调试 Header 问题: 如果你怀疑 Header 配置有问题（例如，认证失败，或者服务器返回非预期的响应），可以使用 webhook.site 或类似的在线工具。将 HTTP 请求节点的 URL 临时改成 webhook.site 提供的地址，然后执行节点。webhook.site 会捕获并显示 n8n 实际发送的完整请求，包括所有的 Headers。你可以将这个实际发送的 Headers 与 API 文档要求进行比对，或者与你在 Postman、curl 等工具中测试成功的请求 Headers 进行比对，从而找出差异。
- 大小写问题: HTTP Header 的名称按照标准应该是不区分大小写的 (case-insensitive)，但现实中，某些服务器的实现可能比较“严格”，只认特定的大小写格式。n8n 默认会将你输入的 Header Name 转换为全小写再发送（可以通过 “Options” -> “Lowercase Headers” 关闭此行为）。如果你遇到因为 Header 大小写导致的问题，可以尝试关闭这个选项，并严格按照 API 文档的大小写来输入 Header Name。
- 特殊 Headers 的影响: 有时，API 的行为会受到 User-Agent 或 Accept Header 的影响。如果你遇到了奇怪的 403 Forbidden 错误，或者 API 返回的数据格式不是你想要的，可以检查一下 API 文档是否对这两个 Header 有特殊要求，并尝试在 n8n 中显式设置它们。
- 动态 Credential 选择: 社区中有用户提出希望能够根据上游数据动态选择使用哪个 n8n Credential（进而影响 Authorization Header）。目前标准的 HTTP 请求节点还不支持直接这样做。如果需要实现这种逻辑，可能需要一些变通方法，比如使用 IF 节点根据条件走向不同的 HTTP 请求节点（每个节点配置不同的 Credential），或者在 Code 节点中根据条件获取对应的 Token 并通过表达式设置到 Header 中。

Send Body (发送请求体)

含义: HTTP Request Body (请求体) 是在 HTTP 请求中承载实际发送的数据的部分，通常用于 POST, PUT, PATCH 这类需要向服务器提交信息的请求方法。它就像是你写的信件的正文内容，包含了你要传递给服务器的具体信息。GET 和 DELETE 请求通常不包含 Body。
配置方式 (Body Content Type): 当你打开 “Send Body” 开关后，首先需要选择 Body Content Type，这决定了你将以哪种格式来组织和发送数据。同时，别忘了在 “Send Headers” 部分设置对应的 Content-Type Header！
- 1. Form URLencoded:
  - 格式: 数据被编码成 key1=value1&key2=value2&... 的字符串形式，类似于 URL 的查询参数，但是放在请求体中发送。
  - 配置:
    - Using Fields Below: 点击 “Add Parameter” 添加 Name 和 Value 对。n8n 会自动将它们编码并组合。
    - Using Single Field: 直接在一个名为 “Body” 的输入框中写入完整的 key1=value1&key2=value2 格式的字符串。Value 部分可以使用表达式。
  - 翔宇场景: 主要用于与那些还在使用传统 Web 表单提交方式的旧系统或 API 进行交互。
  - 对应 Header:Content-Type: application/x-www-form-urlencoded
- 2. Form-Data (multipart/form-data):
  - 格式: 这是一种特殊的格式，设计用来在一次请求中发送包含文件、二进制数据以及普通文本字段的复杂表单数据。数据被分割成多个部分 (parts)，每个部分有自己的描述信息。
  - 配置: 点击 “Add Parameter”，然后为每个参数选择 Parameter Type:
    - Form Data: 用于普通的文本字段。输入字段的 Name 和 Value (Value 可以使用表达式)。
    - n8n Binary File: 用于发送文件或二进制数据。你需要指定：
      - Name: API 文档中要求的文件字段名称（例如 file, image, document）。
      - Input Data Field Name: 包含二进制数据的上游节点输出字段的名称。通常，如果上游节点是 Read Binary File 或另一个返回文件的 HTTP Request 节点，这个字段名就是 data。你需要检查上游节点的输出来确认。
  - 翔宇挑战与技巧:
    - 挑战1: 同时发送 JSON 描述和文件: 这是一个非常常见的需求，例如上传图片时，除了图片本身，还需要附带图片的标题、描述等信息（通常要求是 JSON 格式）。标准的做法是：将 JSON 数据作为一个字符串，通过 Form Data 类型的参数发送；将文件数据通过 n8n Binary File 类型的参数发送。你需要查阅 API 文档，看它要求那个包含 JSON 字符串的字段叫什么名字。
    - 挑战2: 发送多个同名文件参数: 有些 API 允许（甚至要求）在一次请求中上传多个文件，并且这些文件字段使用相同的名称（例如 files）。目前，n8n 的 HTTP 请求节点界面可能不支持直接配置多个同名的 n8n Binary File 参数。遇到这种情况，可能的变通方法包括：
      - 如果 API 允许，将文件先压缩成一个 zip 包再上传。
      - 使用循环结构，每次请求上传一个文件（如果业务逻辑允许）。
      - 在 Code 节点中使用 JavaScript 代码（可能需要额外安装 form-data 库）来手动构建 multipart/form-data 请求体，然后通过 HTTP 请求节点发送 (可能需要用 Raw 模式) 。这对于新手来说比较复杂。
  - 对应 Header:Content-Type: multipart/form-data; boundary=... (n8n 会自动生成 boundary)
- 3. JSON:
  - 格式: 使用标准的 JavaScript Object Notation (JSON) 格式来组织数据，形式为 { "key": "value", "nested": {... }, "array": [... ] }。这是现代 Web API 最常用的数据交换格式。
  - 配置:
    - Using Fields Below: 添加 Name 和 Value 对。n8n 会尝试将这些键值对组合成一个 JSON 对象。对于简单的、扁平的 JSON 结构可能够用。
    - Using JSON: 强烈推荐的方式！ 直接在一个名为 “JSON” 的输入框中写入一个完整的 JSON 字符串。
  - 翔宇强烈建议: 对于任何稍微复杂一点的 JSON 结构（例如包含嵌套对象或数组），或者当你需要动态生成 JSON 内容时，请始终选择 “Using JSON” 模式，并将你的整个 JSON 结构包裹在表达式 {{ }} 中。这是避免各种奇怪错误的最佳实践！
  - 动态 JSON 构建 (核心难点与正确姿势):
    - 错误姿势 1 (表达式未包裹):JSON{ "key": $json.value } // 错误！$json.value 不会被解析 会导致 “JSON parameter needs to be valid JSON” 或类似错误。
    - 错误姿势 2 (表达式在引号内):JSON{ "key": "{{ $json.value }}" } // 错误！值会变成字符串 "{{ $json.value }}" API 收到的将是字面量字符串，而不是动态的值。
    - 正确姿势 (整个 JSON 在表达式内):JSON{{ // 最外层是表达式括号 { // 里面是标准的 JSON 对象 "staticKey": "这是一个固定的值", "dynamicKey": $json.someValue, // 直接引用上游数据 "nestedObject": { "source": $node.json.sourceName, "timestamp": $now.toISO() // 使用内置变量 }, "itemsArray": [ // 可以包含数组 { "id": 1, "name": "item1" }, { "id": {{ $json.itemId }}, "name": "dynamic item" } ] } }} // 最外层是表达式括号 这样 n8n 的表达式引擎会先计算出所有动态值，然后将整个结果构造成一个有效的 JSON 对象发送。
    - 处理特殊字符/换行: 当你动态插入的文本（例如 {{ $json.description }}）本身包含引号 (")、反斜杠 (\) 或换行符 (\n) 时，如果直接用字符串拼接的方式构建 JSON，很容易破坏 JSON 的语法结构。但只要你使用 {{ {... } }} 将整个 JSON 包裹起来，n8n 的表达式引擎通常能够正确地处理这些字符的转义，生成有效的 JSON 。
    - 翔宇排错: 当你遇到 JSON parameter needs to be valid JSON 这个错误时，十有八九是你的动态 JSON 构建语法出了问题。请反复检查：
      1. 是否使用了 “Using JSON” 模式？
      2. 整个 JSON 对象是否被一对 {{ }} 包裹？
      3. JSON 内部的语法是否正确（键值对、逗号、括号等）？
      4. 内部使用的表达式是否能正确引用到数据？
      5. 可以尝试将动态部分暂时替换为静态值，看 JSON 结构本身是否有效（可以用在线 JSON 校验器检查）。
  - 对应 Header:Content-Type: application/json
- 4. n8n Binary File:
  - 格式: 将上游节点输出的单个二进制文件内容，直接作为整个请求体发送。
  - 配置: 只需在 “Input Data Field Name” 中指定包含二进制数据的字段名（通常是 data）。
  - 翔宇场景: 用于与那些设计简单、直接接收文件流作为 Body 的 API 进行交互，例如某些简单的文件存储服务。使用这种模式时，你必须在 “Send Headers” 中手动设置正确的 Content-Type Header，例如 image/jpeg, application/pdf, application/octet-stream (通用二进制流)，否则服务器可能无法识别你发送的是什么文件。
- 5. Raw:
  - 格式: 允许你发送任意格式的原始文本数据。
  - 配置:
    - Content Type: 必须手动输入你发送的数据的 MIME 类型，例如 text/xml, application/graphql, text/csv 等。参考 IANA Media types。
    - Body: 在输入框中直接写入或粘贴你的原始文本数据。可以使用表达式 {{ }} 来动态生成或嵌入内容。
  - 翔宇场景:
    - 发送 XML 数据给 SOAP 服务或旧式 API。
    - 发送 GraphQL 查询语句给 GraphQL API。
    - 发送纯文本、CSV 或其他自定义格式的数据。
    - 在 Code 节点中手动构建了整个请求体（包括 multipart/form-data），然后用 Raw 模式发送（需要同时手动设置 Content-Type Header）。
  - 对应 Header: 需要在 “Send Headers” 中手动设置 Content-Type 为你在 “Raw” 配置中指定的类型。
总结: 选择正确的 “Body Content Type” 并正确地构建请求体，是成功执行 POST/PUT/PATCH 请求的关键。特别是对于最常用的 JSON 格式，掌握 {{ {... } }} 这种动态构建的语法至关重要，它是新手最容易卡壳的地方。务必多加练习，并利用好预览和调试工具。

Options (选项)

在 HTTP 请求节点配置界面的底部，有一个 “Add Option” 按钮，点击它可以添加一系列高级选项，用于更精细地控制节点的行为和处理特殊情况。

Array Format in Query Parameters: (前面讲 Query Parameters 时已提及) 用于控制 URL 查询参数中数组值的格式化方式。根据 API 文档选择正确的格式。
Batching (批处理):
- 含义: 当上游节点传入大量 Item 时，此选项允许你将这些 Item 分成较小的批次进行处理，并且可以在每个批次之间设置一个等待间隔。
- 配置:
  - Items per Batch: 设置每个批次包含多少个 Item。
  - Batch Interval (ms): 设置两个批次请求之间的等待时间（以毫秒为单位）。设置为 0 表示批次之间不等待。
- 翔宇场景 (应对 429 Rate Limit Exceeded 的首选方案): 这是处理 API 速率限制（几乎所有公共 API 都有）最常用且最有效的手段。例如，如果一个 API 限制你每秒最多发送 10 个请求，而你的工作流一次性传入了 100 个 Item 需要处理，你可以设置 Items per Batch 为 10，Batch Interval (ms) 为 1000 (1 秒)。这样 n8n 就会每秒发送 10 个请求，持续 10 秒，从而避免触发速率限制。
- 翔宇技巧:Items per Batch 和 Batch Interval 的具体值需要根据 API 文档中关于速率限制的说明来确定，有时也需要根据实际测试进行调整。如果 API 限制的是并发连接数，可能需要将 Items per Batch 设为 1，并调整 Batch Interval。
Ignore SSL Issues (忽略 SSL 问题):
- 含义: 在建立 HTTPS 连接时，n8n 默认会验证服务器的 SSL/TLS 证书是否有效（例如，是否由受信任的机构颁发、是否过期、域名是否匹配）。勾选此选项会让 n8n 跳过这个验证过程，即使证书有问题也尝试建立连接。
- 风险:这是一个有安全风险的选项！ 忽略 SSL 验证意味着你可能会连接到一个伪造的、不安全的服务器，你的通信数据可能被窃听或篡改（中间人攻击）。
- 翔宇何时使用:强烈不推荐在生产环境中使用！ 仅在以下极少数情况下临时考虑使用：
  - 你在测试环境中连接一个内部服务，你知道它是安全的，但它的 SSL 证书恰好配置有问题（例如自签名证书、证书过期）。
  - 你在调试一个 SSL 连接问题，想暂时排除证书验证的因素。
  - 在任何情况下，使用后都应尽快取消勾选，并解决证书问题。
Lowercase Headers (小写请求头): (前面讲 Headers 时已提及) 决定是否在发送请求前将所有请求头的名称转换为小写。默认是开启的。通常保持默认即可，除非遇到对 Header 大小写特别敏感的 API。
Redirects (重定向):
- 含义: HTTP 协议允许服务器通过返回 3xx 状态码（如 301 Moved Permanently, 302 Found）来告诉客户端请求的资源已经移动到新的 URL。此选项控制 n8n 是否自动跟随这些重定向指令，访问新的 URL 。
- 配置:
  - Redirects: 开关，默认开启 (true)。
  - Max Redirects: 如果开启，这里可以设置最多允许跟随多少次重定向，以防止无限重定向循环。默认值通常是 5 或 10。
- 翔宇建议: 通常保持默认开启状态即可。只有在特殊情况下，比如你明确需要获取重定向之前那个 URL 的响应头时，才需要关闭它。
Response (响应处理): 这个选项组包含了几个关于如何处理和解析 API 响应的重要设置。
- Include Response Headers and Status: (前面讲 Output 时已提及) 强烈推荐在调试时开启！ 默认只输出 Body，开启后会在输出的 json 对象中额外包含 headers, statusCode, statusMessage 字段。这对于判断请求是否成功、获取响应元信息至关重要。
- Never Error (从不报错):
  - 含义: 默认情况下，只有当 API 返回 2xx 范围的状态码 (如 200 OK, 201 Created) 时，n8n 才认为 HTTP 请求节点执行成功。如果 API 返回 4xx (客户端错误，如 404 Not Found) 或 5xx (服务器错误，如 500 Internal Server Error) 状态码，节点会报错并可能停止工作流。勾选 Never Error 后，无论 API 返回什么状态码，该节点都不会报错，而是会将收到的响应（包括错误状态码和可能的错误信息 Body）正常输出。
  - 翔宇场景: 这个选项在你需要主动处理 API 返回的错误时非常有用。例如：
    - 你想实现“如果资源不存在 (404)，就创建它；如果资源已存在 (409 Conflict)，就更新它”的逻辑。你可以开启 Never Error，然后在下游用 IF 节点检查输出的 statusCode，根据不同的值执行不同的分支。
    - 你想记录所有失败的 API 调用详情，而不是让工作流直接停止。
  - 注意: 开启此选项后，你需要自己在下游逻辑中判断请求是否真的成功完成了你期望的操作。
- Response Format (响应格式):
  - 含义: 指示 n8n 应该如何解析收到的响应 Body 。
  - 选项:
    - Autodetect (自动检测): 这是默认选项。n8n 会尝试根据响应头中的 Content-Type 来决定如何解析 Body（例如，看到 application/json 就尝试解析为 JSON，看到 text/plain 就解析为文本）。
    - File (文件): 将响应 Body 直接保存为 n8n 内部的二进制文件数据。你需要同时在 “Put Output in Field” 中指定一个字段名（例如 downloadedFile），用于在输出的 binary 对象中引用这个文件。适用于下载文件。
    - JSON: 强制 n8n 将响应 Body 作为 JSON 来解析。即使 Content-Type 头不是 application/json，n8n 也会尝试这样做。如果 Body 内容确实是有效的 JSON，但服务器没有设置正确的 Content-Type，这个选项可以解决问题。但如果 Body 不是有效 JSON，强制解析会导致错误。
    - Text (文本): 强制 n8n 将响应 Body 作为纯文本处理。你需要同时在 “Put Output in Field” 中指定一个字段名（例如 responseText），用于在输出的 json 对象中存储这个文本。适用于处理 HTML、CSV、纯文本等非 JSON 响应。
  - 翔宇选择: 大多数情况下 Autodetect 就够用了。当你明确知道 API 返回的是特定类型的数据（尤其是文件或非标准 JSON），或者 Autodetect 解析出错时，才需要手动指定 Response Format。
Pagination (分页):
- 含义: 这是一个非常强大的功能，用于自动处理那些将大量数据分成多个“页面”返回的 API 。启用此选项后，n8n 会自动根据你的配置，连续发送请求，直到获取完所有页面的数据，并将所有页面的结果合并后输出。
- 模式 (Pagination Mode): 你需要根据 API 的分页机制选择合适的模式：
  - Off: 关闭分页功能。
  - Update a Parameter in Each Request (在每个请求中更新参数): 适用于 API 通过修改请求参数（通常是 Query Parameter 或 Body Parameter）来控制翻页的情况。例如，通过 page=1, page=2,… 或者 offset=0, offset=50,… 来获取不同页。
    - 配置: 你需要指定要更新的参数的 Type (是 Query 参数还是 Body 参数)、Name (参数名，如 page 或 offset)，以及最关键的 Value 表达式，这个表达式需要根据上一次的请求或响应来计算出下一次请求所需的值。常用的内置变量是 $pageCount (n8n 已经成功获取的页面数量，从 0 开始计数)。例如，如果 API 页码从 1 开始，Value 表达式通常是 {{ $pageCount + 1 }}。如果 API 使用基于上次响应的 cursor，表达式可能是 {{ $response.body.nextCursor }}。
  - Response Contains Next URL (响应包含下一个 URL): 适用于 API 在每次响应中直接提供下一页数据的完整 URL 的情况。
    - 配置: 你需要在 Next URL 字段中提供一个表达式，该表达式能从上一次的响应数据中提取出下一页的 URL。例如，如果 API 在响应 Body 的 pagination.next_url 字段中提供了链接，表达式可以是 {{ $response.body.pagination.next_url }}。如果链接在响应头的 Link Header 中（遵循 RFC 5988 格式），你可能需要更复杂的表达式来解析它。
- 翔宇处理大数据集经验:
  - 分页是必备技能: 当你需要从 API 获取可能包含成百上千条记录的数据时，分页是必须掌握的。不处理分页，你可能只能拿到第一页的几十条数据。
  - 阅读 API 文档: 再次强调，必须仔细阅读 API 文档关于分页的部分，了解它是基于页码 (page)、偏移量 (offset)、游标 (cursor)、还是下一页链接 (next URL) 来工作的，以及相关的参数名称和格式。
  - 利用内置变量:$pageCount (已获取页数，从 0 计), $response (上次的完整响应对象，包括 body, headers, statusCode), $request (上次发出的请求对象) 是你在分页表达式中最常使用的武器。
  - 停止条件: n8n 会在以下情况自动停止分页：API 返回的响应中不再包含下一页的信息（例如 next URL 为 null 或空），或者 API 返回了空的数据集，或者达到了 n8n 内部的一些限制（可以通过环境变量调整，但不常用）。
  - 分页与批处理结合: 如果 API 对请求频率也有限制，你可以同时启用 Pagination 和 Batching。n8n 会先处理分页逻辑，然后将生成的多个请求再应用批处理规则。
Proxy (代理):
- 含义: 允许你的 HTTP 请求通过一个指定的代理服务器来发送，而不是直接从 n8n 所在的服务器发出。
- 配置: 在 “Proxy” 字段中输入代理服务器的 URL，格式通常是 http://<proxy_host>:<proxy_port> 或 https://<proxy_host>:<proxy_port>。如果代理需要认证，可能还需要配置用户名和密码（n8n 可能通过环境变量或特定凭据类型支持）。
- 翔宇网络环境配置: 这个选项主要用于以下场景：
  - 你的 n8n 实例运行在公司内网，需要通过指定的 HTTP 代理才能访问外部互联网上的 API。
  - 你希望隐藏 n8n 服务器的真实 IP 地址，通过代理进行访问。
Timeout (超时):
- 含义: 设置 n8n 等待服务器开始发送响应（即收到响应头）的最长时间，单位是毫秒。如果在这个时间内服务器没有任何响应，n8n 会中止请求并报错（例如 ETIMEDOUT 或 ESOCKETTIMEDOUT）。
- 配置: 在 “Timeout” 字段输入超时时间值，例如 60000 代表 60 秒。n8n 有一个默认的超时时间（通常是几十秒），你可以根据需要调整。
- 翔宇避免超时策略:
  - 如果某个 API 响应特别慢，你可能需要适当增加 Timeout 值，给服务器更多处理时间。
  - 但是，设置过长的 Timeout 也不是好事，如果 API 真的卡住了，你的工作流也会跟着卡住很久。
  - 超时错误有时是临时的网络波动或服务器负载高导致的。结合后面会讲到的 Retry On Fail 设置，可以在发生超时错误时自动重试几次，提高工作流的稳定性。

Node Settings (节点设置 – Settings Tab)

除了上述在主配置界面通过 “Add Option” 添加的选项外，点击节点右上角的齿轮图标，切换到 “Settings” 标签页，还有一些控制节点行为的重要设置。

Always Output Data (总是输出数据):
- 含义: 默认情况下，如果节点执行失败，或者 API 调用成功但没有返回任何数据 (例如，查询结果为空)，该节点可能不会产生任何输出 Item。勾选此选项后，即使在这些情况下，节点也会强制输出一个空的 Item ({ "json": {} })。
- 翔宇提示: 这个选项在某些需要确保下游节点（尤其是 Merge 节点或需要固定输入的节点）总能收到输入的场景下有用。但是，要特别小心在 IF 节点之后使用它，如果 IF 的 false 分支没有输出，而你又把这个节点的输出连接回 IF 节点之前的某个地方，可能会造成无限循环！
Execute Once (执行一次):
- 含义: 无论上游节点传入了多少个 Item，勾选此选项后，HTTP 请求节点将只执行一次 。它会使用第一个传入 Item 的数据来构建和发送请求。后续传入的 Item 都将被忽略。
- 翔宇场景: 当你的工作流逻辑是基于某个触发事件（例如 Webhook 触发），只需要根据这个触发事件的信息调用一次 API，而不需要对后续可能存在的（或误传入的）多个 Item 进行重复调用时，这个选项非常有用。它可以防止意外地发送大量请求。例如，你想在收到新订单 Webhook 时，调用一次 API 来更新订单状态。
Retry On Fail (失败时重试):
- 含义: 这是提升工作流健壮性的一个关键设置 。当 HTTP 请求节点执行失败时（例如，因为网络临时中断、API 服务器暂时过载返回 503 Service Unavailable、或者触发了速率限制返回 429），勾选此选项可以让 n8n 自动尝试重新执行该节点。
- 配置:
  - Max Tries: 设置最大允许重试的次数（例如，设置为 3 表示最多尝试 1 次原始执行 + 3 次重试 = 4 次）。
  - Wait Between Tries (ms): 设置每次重试之间的等待时间（以毫秒为单位）。例如，设置为 5000 表示每次重试前等待 5 秒。
- 翔宇工作流健壮性配置: 对于那些与外部系统交互的关键 HTTP 请求节点，强烈建议启用此选项 。网络和 API 服务不总是 100% 可靠的，自动重试可以大大增加工作流成功完成的机会。你需要根据 API 的特性和错误类型，合理设置重试次数和间隔。例如，对于 429 错误，等待间隔可能需要长一些，以符合 API 的速率限制要求。
- 注意: 不是所有的错误都适合重试。例如，400 Bad Request (请求本身格式错误) 或 401 Unauthorized (认证失败) 通常重试多少次都是一样的结果，重试反而浪费资源。Retry On Fail 主要适用于那些临时性的、有望通过重试解决的错误。
On Error (出错时):
- 含义: 这个设置定义了当 HTTP 请求节点执行遇到无法通过重试解决的错误时，整个工作流应该如何继续。
- 选项:
  - Stop Workflow (默认): 一旦节点报错，整个工作流的执行将立即停止。
  - Continue (继续 – 使用上次有效数据): 节点报错，但工作流会继续执行下游节点。下游节点收到的输入数据将是上一次该 HTTP 请求节点成功执行时的输出数据（如果之前从未成功过，则可能没有数据）。这种模式使用场景较少，需要非常小心。
  - Continue (using error output) (继续 – 使用错误输出): 节点报错，但工作流会继续执行。与 Continue 不同的是，它会将错误信息本身作为输出传递给下游节点。错误信息通常包含错误代码、错误消息、发生错误的节点和工作流信息等。
- 翔宇错误处理:Continue (using error output) 是实现自定义错误处理逻辑的关键。你可以将错误输出连接到一个专门的错误处理分支。在这个分支里，你可以：
  - 使用 Set 节点提取错误信息。
  - 使用 Log 节点记录错误详情。
  - 使用 Notify 节点（如 Email, Slack）发送错误告警。
  - 甚至可以根据错误类型，尝试执行一些补救措施（例如，调用另一个备用 API）。
  - 社区中有用户尝试利用这个选项配合 Wait 和 Loop 来实现更复杂的重试逻辑，但遇到了 Item 被复制的问题，这表明用它来实现重试需要谨慎设计，可能不如内置的 Retry On Fail 方便。
Notes (备注) & Display note in flow (在流程中显示备注):
- 含义: 允许你为节点添加文字备注信息，解释这个节点的作用、配置逻辑或注意事项。如果勾选 “Display note in flow”，备注会作为节点的副标题直接显示在工作流画布上。
- 翔宇建议: 对于配置复杂（尤其是表达式复杂）的 HTTP 请求节点，或者在团队协作的工作流中，务必添加清晰的备注。好记性不如烂笔头，几个月后回来看，或者别人接手时，这些备注能帮你快速理解节点的用途。

总结: Options 和 Settings 中的这些选项，提供了超越基本请求发送的高级控制能力。它们是处理现实世界中各种 API “怪癖”（如速率限制、不稳定、错误响应）和提升工作流健壮性、实现精细化错误处理的关键工具。特别是 Batching, Retry On Fail, 和 On Error (using error output)，是在构建生产级别的、可靠的自动化工作流时必须理解和善用的功能。

数据映射与表达式 (重点)

表达式是 n8n 实现动态自动化流程的“魔法棒”。在 HTTP 请求节点中，无论是动态构建 URL、设置请求头，还是生成请求体，都离不开表达式。掌握表达式的用法，是真正用活 HTTP 请求节点的关键，也是新手最容易感到困惑的地方。

表达式基础语法与常用变量

基础语法: 在 n8n 中，当你想要插入动态值或执行简单计算时，你需要使用表达式。表达式需要被包裹在双花括号 {{ }} 中。括号内的内容遵循 JavaScript 语法。
常用变量/对象: 在 {{ }} 内部，你可以访问一系列 n8n 提供的内置变量和对象，来获取工作流中其他地方的数据：
- $json: 这是最常用的变量，没有之一。它代表当前正在被节点处理的那个 Item 的 json 对象。你可以通过点 . 或方括号 “ 来访问 json 对象下的属性（即字段）。
  - 示例：{{ $json.propertyName }} (如果字段名简单)
  - 示例：{{ $json["property-with-hyphens"] }} (如果字段名包含特殊字符，用方括号和引号)
  - 示例：{{ $json.user.address.city }} (访问嵌套对象的属性)
- $input: 代表当前正在处理的 Item 的完整输入对象，它本身包含 json 属性，可能还包含 binary 属性（如果上游节点输出了二进制数据）。通常我们直接用 $json 就够了，但在某些需要访问二进制数据信息或在特定函数（如 .map() 循环内部）引用当前 Item 时可能会用到。例如 $input.item.json.propertyName (在某些循环上下文)。 $input.all() 则可以获取节点收到的所有输入 Items 的数组。
- $node: 用于引用其他节点的输出数据。你需要使用节点的名称来指定是哪个节点。
  - 示例：{{ $node["上一个节点名称"].json.某个字段 }}
  - 注意: 节点名称区分大小写，并且如果名称包含空格或特殊字符，必须用方括号和引号括起来。如果节点输出了多个 Item，默认情况下这会引用第一个 Item 的数据。
- $item(index): 用于按索引（位置）引用当前节点收到的输入 Item 。$item(0) 代表第一个输入的 Item，$item(1) 代表第二个，以此类推。
  - 示例：{{ $item(0).json.propertyName }} (获取第一个输入 Item 的 propertyName 字段)
  - 注意: 这与 $node 不同，$node 引用的是其他节点的输出，而 $item 引用的是当前节点的输入。
- $items(nodeName, runIndex, outputIndex): 这是一个更高级、更精确的引用方式，用于获取指定节点 (nodeName) 在特定运行 (runIndex，通常是 0) 的特定输出 (outputIndex，通常是 0) 中的所有 Item 数据。当你需要处理来自其他节点的多个输出，或者在循环/批处理中需要精确控制数据来源时可能会用到。例如，{{ $items("数据准备节点").json.value }} 获取名为 “数据准备节点” 的第一个输出的第一个 Item 的 value 字段。
- $runIndex: 代表当前 Item 在本次节点执行中的索引号（从 0 开始计数）。在处理多个 Item 的循环或批处理中非常有用，可以用来生成序号、或者从其他节点的对应 Item 中取数据（例如 {{ $items("节点A")[runIndex].json.value }}）。
- $workflow: 引用当前工作流的一些元信息，例如工作流的 ID ($workflow.id) 或名称 ($workflow.name)。
- $env: 用于引用你在 n8n 运行环境中设置的环境变量。这对于管理 API 密钥、主机名等配置信息非常有用，避免将它们硬编码在工作流中。
  - 示例：{{ $env.MY_API_KEY }} (引用名为 MY_API_KEY 的环境变量)
- 内置方法和变量: n8n 还提供了一些方便的内置变量和方法，例如：
  - $now: 获取当前的日期和时间对象 (可以使用 .toISO(), .toFormat('yyyy-MM-dd') 等方法格式化)。
  - $today: 获取今天的日期对象。
  - 还有一些用于数据转换的函数，可以在 Code 节点或 Function 节点中使用，有时简单的也可以直接在表达式中使用。
翔宇类比: 你可以把表达式想象成给 n8n 下达的一个寻宝指令。{{ }} 是指令的开始和结束符。里面的 $json, $node["节点名"], $item(0) 等就像是告诉你去哪个藏宝点（当前 Item？某个特定节点？第一个输入？）；而后面的 .字段名 或 ["字段名"] 就像是告诉你具体要找哪个宝箱（哪个字段）；最终找到的就是你需要的值。

在 URL, Headers, Body 中使用表达式动态构建请求

现在我们把表达式应用到 HTTP 请求节点的关键参数中：

URL: (前面已详细介绍过)
- 动态路径: https://api.example.com/orders/{{ $json.orderId }}
- 动态查询参数: https://api.example.com/search?q={{ $json.query }}&lang={{ $env.LANGUAGE }}
- 组合: https://{{ $node["Config"].json.host }}/users/{{ $json.userId }}/profile
Headers: (前面已详细介绍过)
- Value (Using Fields Below):
  - Name: Authorization
  - Value: Bearer {{ $node.json.access_token }}
  - Name: X-User-ID
  - Value: {{ $json.userId }}
- JSON Mode (Using JSON):JSON{{ // 别忘了最外层的 {{ }} { "Content-Type": "application/json", "Authorization": "ApiKey " + $env.SERVICE_API_KEY, // 字符串拼接 "X-Correlation-ID": $workflow.executionId + '-' + $runIndex // 组合工作流和运行信息 } }}
Body: (前面已详细介绍过，这里重点强调 JSON 模式)
- Form URLencoded / Form-Data (Using Fields Below):
  - Name: username
  - Value: {{ $json.name.toUpperCase() }} (可以使用 JavaScript 函数)
  - Name: file (Parameter Type: n8n Binary File)
  - Input Data Field Name: data (引用上游二进制数据)
- JSON (Using JSON Mode):这是核心中的核心，也是最容易出错的地方！
  - 正确姿势:JSON{{ // 必须有最外层的 {{ }} { // 标准 JSON 对象 "productId": {{ $json.id }}, // 数字类型，不需要引号 "productName": "{{ $json.name }}", // 字符串类型，需要引号，但值是动态的 "description": "来自节点 '{{ $node.name }}' 的数据", // 字符串拼接 "attributes": { // 嵌套对象 "color": "{{ $json.color |

| ‘default_color’ }}”, // 使用默认值

“size”: {{ $json.size }}

“tags”: [ // 数组

“tag1”,

“{{ $json.category }}” // 动态数组元素

“price”: {{ parseFloat($json.price).toFixed(2) }} // 使用 JS 函数处理数字

}

}} // 必须有最外层的 {{ }}

10 * Raw:* Content Type: `text/xml` * Body:xml

{{

” + $json.username + ” + $json.payload + ”

}}

“`

(注意 XML 字符串拼接可能需要更复杂的处理，例如转义特殊字符，通常建议在 Code 节点中准备好 XML 字符串)

翔宇技巧:
- 拖拽大法好: 对于新手来说，最快上手的方式就是在节点配置界面，将左侧 Input Data 面板中你想要引用的字段，直接拖拽到右侧的参数输入框中。n8n 会自动为你生成基础的表达式，例如 {{ $json.fieldName }}。你可以在此基础上进行修改。
- 善用表达式编辑器: 点击参数输入框旁边的小图标（通常是 “fx” 或齿轮图标），可以打开表达式编辑器。它提供了语法高亮、自动补全（部分）、以及最重要的——实时预览功能。你可以在编辑器里修改表达式，并立刻看到它基于当前节点的输入数据计算出的结果，这对于调试复杂表达式非常有帮助。
- 字符串与变量拼接: 使用 JavaScript 的 + 号来连接固定的字符串和动态的表达式。例如 Bearer {{ $json.token }} 或者 {{ "订单号：" + $json.orderNumber }}。
- 调用 JavaScript 函数: 你可以在 {{ }} 中直接调用 JavaScript 的内置函数（主要是字符串、数字、数组的一些简单方法），例如：
  - .toUpperCase() / .toLowerCase(): 转换大小写。
  - .slice(startIndex, endIndex): 截取字符串或数组的一部分。
  - .split(separator): 将字符串分割成数组。
  - .join(separator): 将数组元素连接成字符串。
  - .toFixed(digits): 将数字格式化为指定小数位数。
  - .toString(): 转换为字符串。
  - parseInt(string) / parseFloat(string): 将字符串转换为整数/浮点数。
  - 对于更复杂的逻辑（如循环处理数组、复杂的条件判断），建议在 HTTP 请求节点之前添加一个 Code 节点 或 Function 节点进行数据预处理，让 HTTP 节点中的表达式保持简单。
- 简单条件逻辑 (三元运算符): 如果只是简单的二选一逻辑，可以使用三元运算符 condition? value_if_true : value_if_false。
  - 示例：{{ $json.status === 'active'? '启用' : '禁用' }}
  - 示例：{{ $json.score >= 60? 'pass' : 'fail' }}
  - 更复杂的 if-else 逻辑，同样建议使用 Code/Function 节点。

映射技巧与常见易错点

数据映射就是将上游节点的数据，通过表达式正确地应用到 HTTP 请求节点的参数中的过程。这里总结一些实战中的技巧和最容易踩的坑：

易错点 1: JSON 格式错误 (最高频！)
- 症状: 节点报错 “JSON parameter needs to be valid JSON”。
- 原因:
  1. 在 Body (JSON Mode) 中，没有用 {{ }} 将整个 JSON 对象包裹起来。
  2. 在 Body (JSON Mode) 中，动态插入的字符串值没有被引号 "" 包裹，或者字符串本身包含未转义的引号或换行符，破坏了 JSON 结构。
  3. JSON 语法本身错误，例如缺少逗号、多了逗号、括号不匹配等。
  4. 表达式直接放在了 JSON 值的位置，例如 { "key": $json.value } 而不是 { "key": "{{ $json.value }}" } (在非 {{ {... } }} 包裹模式下) 或 {{ { "key": $json.value } }} (在推荐的包裹模式下)。
- 翔宇调试技巧:
  - 第一步：确认包裹！ 检查 Body (JSON Mode) 的内容是否是以 {{ 开始，并以 }} 结束，且中间是一个合法的 JavaScript 对象字面量。
  - 第二步：校验静态部分！ 暂时将所有表达式替换为静态值，然后将整个 JSON 复制出来，粘贴到在线的 JSON 校验器（例如 jsonlint.com）中检查语法是否正确。
  - 第三步：简化表达式！ 如果静态部分没问题，那就逐个检查动态表达式。从最简单的开始，例如 {{ { "key": $json.value } }}，看是否能运行。然后逐步添加更复杂的表达式和嵌套结构。
  - 第四步：检查引号！ 确保所有期望是字符串类型的值（无论是静态的还是动态生成的）都被双引号 "" 包裹。数字和布尔值不需要引号。
  - 第五步：利用预览！ 在表达式编辑器中查看预览结果，看生成的 JSON 结构是否符合预期。
易错点 2: 引用未执行节点数据
- 症状: 节点报错 “Can’t get data for expression” 或 “Referenced node is unexecuted”。
- 原因: 你的表达式（例如 {{ $node["某个节点"].json.value }}）引用了一个在当前工作流执行路径中还没有运行到的节点的数据。可能是因为：
  - 你把节点连线接错了，引用的节点在当前节点的下游。
  - 工作流中有 IF 或 Switch 节点，导致引用的节点在本次执行中被跳过了。
- 翔宇调试技巧:
  - 检查工作流的连线，确保数据流向正确，被引用的节点确实在当前节点之前执行。
  - 运行一次工作流，查看 Execution Log，确认被引用的节点是否真的执行了，并且输出了你期望的数据。
  - 如果引用节点可能被跳过，可以在表达式中使用默认值，或者在 Code/Function 节点中加入判断逻辑，例如检查 $node["某个节点"].isExecuted 属性。
易错点 3: 作用域/索引问题 (尤其在 Batching/Looping 中)
- 症状: 节点不报错，但发送的请求数据不正确，例如所有请求都使用了第一个 Item 的数据，或者引用其他节点数据时出错。
- 原因: 当 HTTP 请求节点处理多个 Item 时（例如上游输出了一个列表，或者使用了 Batching），如果你在表达式中简单地使用 $node["其他节点"].json.value，它可能总是引用 “其他节点” 输出的第一个 Item 的数据，而不是与当前正在处理的 Item 相对应的数据。
- 翔宇调试技巧:
  - 优先使用 $json: 在处理当前 Item 的数据时，尽量使用 $json 来引用当前 Item 自身的字段，例如 {{ $json.id }}。
  - 使用 $runIndex: 如果你需要引用其他节点输出的、与当前 Item 位置对应的数据，可以使用 $runIndex。例如，假设节点 A 和节点 B 都输出了 10 个 Item，你在节点 C 中处理节点 B 的第 i 个 Item 时，想引用节点 A 的第 i 个 Item 的 value 字段，可以使用 {{ $items("节点 A")[$runIndex].json.value }}。
  - 理解 $item(0) vs $json:$item(0) 总是引用输入的第一个 Item，而 $json 引用的是当前正在处理的 Item 的 json 部分。在循环或批处理中，通常应该用 $json 或基于 $runIndex 的引用。社区中有用户通过将 $node[...] 修改为 $items("...", 0) 的方式解决了批处理中表达式解析的问题，这本质上是强制每次都引用第一个 Item，适用于某些特定场景。
易错点 4: 数据类型不匹配
- 症状: API 返回错误，提示参数类型不正确，或者请求成功但数据处理异常。
- 原因: 你的表达式返回的数据类型（例如数字）与 API 期望接收的类型（例如字符串）不符。
- 翔宇调试技巧:
  - 检查 API 文档对参数类型的要求。
  - 在表达式中使用 JavaScript 函数进行转换，例如：
    - 数字转字符串: {{ $json.numberValue.toString() }}
    - 字符串转整数: {{ parseInt($json.stringValue) }}
    - 字符串转浮点数: {{ parseFloat($json.stringValue) }}
    - 确保布尔值是 true/false 而不是字符串 "true"/"false" (除非 API 特殊要求)。
易错点 5: Null / Undefined 值处理不当
- 症状: 节点报错（例如尝试访问 null 的属性），或者 API 请求失败，或者发送了包含空值的无效数据。
- 原因: 表达式引用的字段在上游数据中不存在，或者其值本身就是 null 或 undefined。
- 翔宇调试技巧:
  - 提供默认值: 使用 || 操作符提供一个默认值。例如，如果 color 字段可能不存在，可以用 {{ $json.color | | "默认颜色" }}。
  - 条件判断: 在 Code/Function 节点中进行预处理，检查字段是否存在或有值，再决定如何构建数据。
  - API 容错性: 了解 API 如何处理可选参数或空值。有些 API 允许省略可选参数，有些则要求传递 null 或空字符串。
翔宇调试心得总结:
- 分步细化，逐个击破: 不要期望一次就能写对包含多个动态部分的复杂请求。先用静态值让请求跑通，然后一次只替换一个部分为表达式，测试成功后再替换下一个。
- 预览是你的好朋友: 反复利用表达式编辑器和节点执行后的 Output Data 面板来查看表达式的计算结果和节点的实际输入输出。这是最直接的反馈。
- 保持简单: 如果一个节点的表达式变得极其复杂、难以阅读和维护，就应该考虑拆分逻辑。在前面增加一个 Set 节点（用于简单的数据转换和组合）或 Code 节点（用于更复杂的逻辑处理），专门负责准备好 HTTP 请求节点所需的数据结构。这样可以让 HTTP 请求节点本身的配置（尤其是 Body 部分的表达式）变得非常简洁明了。

掌握表达式和数据映射是精通 n8n HTTP 请求节点的关键一步。虽然初期可能会遇到一些挫折，但只要理解了基本原理，掌握了调试方法，并勤加练习，你就能运用自如，构建出强大的动态自动化流程。

应用场景

HTTP 请求节点的通用性意味着它的应用场景极其广泛。可以说，只要你需要让 n8n 与一个提供了 Web API 的外部系统进行交互，而 n8n 又没有提供该系统的专用节点时，HTTP 请求节点就是你的首选工具。以下是我（翔宇）在实际工作中经常使用 HTTP 请求节点的一些场景，希望能给你带来启发：

调用第三方 API 获取数据: 这是最基础也是最常见的用途。
- 公共 API 数据: 例如，调用天气 API 获取指定城市的天气预报，调用财经 API 获取股票实时价格，调用新闻 API 聚合特定主题的资讯，或者像社区里有人分享的那样，调用 NASA API 获取每日天文图片。
- 特定业务系统数据: 查询你公司内部使用的 CRM 系统（如果它有 API）获取客户信息，查询 ERP 系统获取库存状态，或者从项目管理工具（如 Jira，如果不用专用节点）查询任务详情。
- 翔宇提示: 这类场景的关键在于找到目标服务的 API 文档，确定你需要获取哪个资源 (URL)，使用什么方法 (通常是 GET)，需要提供哪些认证信息 (Authentication)，以及是否需要通过查询参数 (Query Parameters) 来筛选或指定范围。
向第三方 API 提交数据: 将 n8n 工作流中产生或获取的数据发送给外部系统。
- 数据录入/更新: 将在线表单 (如 Typeform, Google Forms) 提交的数据，通过 API 写入到你的项目管理工具 (如 Trello, Asana，即使它们有专用节点，有时你也可能需要调用专用节点不支持的 API 功能)、自定义数据库、或内部业务系统中。
- 发送自定义通知: 将工作流产生的告警、报告或消息，通过 API 发送到那些 n8n 没有原生支持的通信平台，例如企业微信的机器人、钉钉的自定义机器人、或者某些小众的即时通讯工具。
- 触发外部操作: 调用 API 来触发另一个系统的动作，比如，当 n8n 检测到某个条件满足时，调用 Jenkins API 触发一个构建任务，或者调用一个云服务的 API 来启动或停止一个虚拟机。
- 翔宇提示: 这类场景的关键是确定正确的请求方法 (通常是 POST 用于创建，PUT 或 PATCH 用于更新)，配置好认证 (Authentication) 和必要的请求头 (Headers，特别是 Content-Type)，并根据 API 文档的要求，在请求体 (Body) 中构建好要发送的数据（通常是 JSON 格式）。
Webhook 交互: Webhook 是一种常见的系统间实时通信机制。
- 响应 Webhook: 虽然 n8n 有专门的 Webhook 触发节点来接收外部系统发送的 POST 请求，但在某些复杂的场景下，你可能需要在收到 Webhook 后，再通过 HTTP 请求节点调用发送方的 API 来获取更多信息或确认接收状态。
- 发送 Webhook: 向那些需要通过 Webhook 接收通知或数据的系统发送请求（通常是 POST 请求，Body 中包含需要传递的数据）。
数据同步: 在不同的系统之间保持数据的一致性。
- 单向同步: 例如，当你的电商平台 (如 Shopify) 产生新订单时，自动将订单的关键信息（客户、商品、金额等）通过 API 同步到你的财务软件或库存管理系统中。
- 双向同步 (更复杂): 在两个系统间相互同步数据更新。这通常需要更复杂的逻辑来处理冲突和避免无限循环，HTTP 请求节点是实现这种交互的基础。
文件上传/下载: 处理文件相关的 API 操作。
- 上传文件: 将 n8n 工作流中生成或获取的文件（例如，报告 PDF、用户上传的图片）通过 API 上传到云存储服务 (如 AWS S3, Google Cloud Storage，如果不用专用节点的话)、文档管理系统、或者特定的应用（如将视频上传到 YouTube ，将文件推送到 Password Pusher ）。
- 下载文件: 从一个给定的 URL 下载文件，并将其作为二进制数据传递给 n8n 的后续节点进行处理（例如，保存到本地、发送到邮件附件、或者上传到另一个地方）。
- 翔宇提示: 文件上传通常需要使用 multipart/form-data 格式的请求体，并且要正确引用包含文件二进制数据的字段（通常是 data）。下载文件则通常是 GET 请求，需要将响应格式 (Response Format) 设置为 File。
监控网站/API 变化:
- 设置一个定时触发的工作流，定期使用 HTTP 请求节点访问某个网页的 URL 或 API 端点。
- 将本次获取的响应内容与上一次运行存储的结果进行比较（可以使用 Static Data 或外部存储）。
- 如果内容发生了变化，就触发一个通知（例如发送到 Telegram 或 Slack）。这对于监控竞争对手网站更新、或者检查某个 API 是否返回预期数据很有用。
与 AI 服务交互: 随着 AI 的兴起，这也是一个越来越重要的场景。
- 直接调用大模型 API: 使用 HTTP 请求节点直接调用 OpenAI (ChatGPT), Google Gemini, Anthropic Claude, Grok , Perplexity 等大语言模型的 API 接口，传入你的 Prompt，获取生成的文本、代码或分析结果。你需要根据各家 AI 服务的 API 文档配置 URL, Headers (Authorization, Content-Type) 和 Body (通常是包含模型名称、消息列表等参数的 JSON)。
- 作为 AI Agent 的工具 (Tool): 在 n8n 的 AI Agent 框架中，你可以将 HTTP 请求节点配置为一个“工具”，让 AI Agent 能够根据用户的指令，自主地决定调用哪个外部 API 来获取实时信息（例如查询天气、搜索新闻）或执行某个操作（例如预订会议室、发送邮件）。这极大地扩展了 AI Agent 的能力。
翔宇总结: 以上只是冰山一角。HTTP 请求节点的真正威力在于它的无限可能性。只要你需要连接的系统或服务提供了 HTTP API 接口（无论是公开的还是内部的，无论是 RESTful 还是其他风格），HTTP 请求节点就能充当起连接它们的桥梁。发挥你的想象力，结合你的实际需求，你会发现它能帮你实现各种曾经认为只有程序员才能做到的自动化任务。

常见报错及解决方案 (实用)

在使用 HTTP 请求节点时，遇到错误是在所难免的，尤其是在刚开始学习的时候。关键在于不要害怕错误，而是要学会看懂错误信息，并掌握一套有效的排错方法。下面我将结合常见的错误提示和社区里大家经常遇到的问题，分享一些实用的排错思路和技巧。

错误提示解析与排错思路

以下是一些你在使用 HTTP 请求节点时最可能遇到的错误提示，以及对应的原因分析和翔宇的排错建议：

400 Bad Request - please check your parameters (400 错误请求 – 请检查您的参数)
- 原因: 这个错误表明服务器认为你的请求格式有问题，无法理解或处理。最常见的原因是：
  - URL 中的查询参数 (Query Parameter) 名称或值不符合 API 的要求（例如，参数名拼写错误，值类型不对，或者缺少必填参数）。
  - 请求体 (Body) 的格式不正确，特别是当 Body Content Type 是 JSON 时，你提供的不是一个有效的 JSON 对象 。
  - 请求体 (Body) 中的某个字段值不符合 API 的校验规则（例如，长度超限，格式错误）。
  - 在查询参数中传递数组时，数组格式 (Array Format) 没有按照 API 文档的要求进行设置。
- 翔宇排错:
  1. 核对 API 文档: 仔细检查 API 文档中关于该操作的请求参数（包括 Query Parameters 和 Body Parameters）的要求，确认参数名称、大小写、是否必填、数据类型、格式等都完全匹配。
  2. 检查 JSON 语法: 如果你发送的是 JSON Body，请重点检查 JSON 语法的有效性，特别是动态构建 JSON 时的表达式是否正确（参考前面表达式部分的易错点）。使用在线 JSON 校验器辅助检查。
  3. 检查查询参数: 确认 Query Parameters 的名称和值都正确，如果传递了数组，检查 Array Format 选项是否设置正确。
  4. 简化请求: 尝试移除一些非必填的参数，看是否能成功。如果成功，再逐个加回参数，定位到具体是哪个参数导致的问题。
401 Unauthorized / 403 Forbidden - perhaps check your credentials (401 未授权 / 403 禁止访问 – 也许检查您的凭据)
- 原因: 这两个错误都表示认证失败 。
  - 401 Unauthorized 通常意味着你没有提供凭据，或者提供的凭据格式错误、无效或已过期（例如，Token 过期了）。服务器根本不知道你是谁。
  - 403 Forbidden 通常意味着你提供的凭据是有效的，服务器认出了你，但是你没有足够的权限来执行你请求的操作。比如，你的 API Key 只有读取权限，但你尝试进行写入操作。
- 翔宇排错:
  1. 检查认证配置: 仔细检查你在 “Authentication” 部分的配置是否正确。
    - 使用的是 Predefined Credential 还是 Generic Credential？
    - 如果是 Generic Header Auth，Header Name (如 Authorization, X-API-Key) 和 Value (如 Bearer <token>, <api_key>) 是否完全符合 API 文档要求？Bearer 后面有没有空格？Token 是否完整？
    - 如果是 Basic Auth，用户名和密码是否正确？
    - 如果是 OAuth 1/2，配置是否完整且正确？Token 是否已过期需要刷新？
  2. 使用 n8n Credentials: 强烈建议将敏感凭据存储在 n8n 的 Credentials 系统中，并在节点中引用，而不是直接硬编码。检查引用的 Credential 是否选择正确。
  3. 检查权限: 如果是 403 错误，需要去 API 提供方的管理后台检查你使用的账户或 API Key 是否被授予了执行该操作所需的权限（Scope 或 Permission）。
  4. 尝试不同认证方式: 如果使用 Predefined Credential 失败，可以尝试改用 Generic Header Auth 手动配置 Header，反之亦然，用于排查是否是 n8n 凭据管理或节点本身的问题。
  5. 检查 Token/Key 有效期: 确认你使用的 Token 或 API Key 是否仍在有效期内。
404 Not Found - The resource you are requesting could not be found (404 未找到 – 无法找到您请求的资源)
- 原因: 这个错误非常直白，就是服务器找不到你请求的那个 URL 对应的资源。
- 翔宇排错:
  1. 检查 URL 拼写: 最常见的原因是 URL 输入错误。仔细核对每一个字符，包括协议 (http/https)、主机名、路径、斜杠 / 等。多一个或少一个字符都不行。最好从 API 文档直接复制粘贴。
  2. 检查动态 URL: 如果 URL 是动态构建的（使用了表达式），请检查表达式引用的值是否正确，最终生成的 URL 是否符合预期。可以在 Set 节点或日志中输出生成的 URL 查看。
  3. 确认 API 端点有效: 检查该 API 端点是否已经被废弃 (Deprecated) 或者发生了变更。查阅最新的 API 文档。
  4. 检查 Base URL: 确认你使用的 API Base URL 是否正确。
429 Too Many Requests - The service is receiving too many requests from you (429 请求过多 – 服务正在接收来自您的过多请求)
- 原因: 你在短时间内发送的请求次数超过了 API 服务器设定的速率限制 (Rate Limit) 。这是非常常见的错误，尤其是在处理大量数据或工作流触发频繁时。
- 翔宇排错:
  1. 启用 Batching: 这是首选解决方案。在节点的 “Options” 中添加 “Batching”，设置合适的 Items per Batch (每批处理多少个 Item) 和 Batch Interval (ms) (批次间的等待时间)。你需要参考 API 文档关于速率限制的说明（例如，每秒/每分钟允许多少次请求）来计算合理的批处理参数。
  2. 启用 Retry On Fail: 在节点的 “Settings” 中启用 “Retry On Fail”，并设置合适的 Wait Between Tries (ms)。当收到 429 错误时，让 n8n 等待一段时间后再重试，可能会成功。通常需要配合 Batching 使用。
  3. 添加 Wait 节点: 如果 Batching 不够灵活，可以在工作流中显式添加 Wait 节点，在每次（或每批）HTTP 请求之后强制等待一段时间。
  4. 优化工作流逻辑: 检查你的工作流设计，是否真的需要发送这么多请求？能否通过一次请求获取更多数据？能否减少触发频率？
  5. 检查输入 Item 数量: 再次强调，注意上游节点传入了多少个 Item，因为 HTTP 请求节点默认会对每个 Item 发起一次请求。如果不需要对每个 Item 都请求，考虑使用 Execute Once 设置。
JSON parameter need to be an valid JSON (JSON 参数需要是有效的 JSON)
- 原因: 当你在 Body (选择了 JSON Content Type 并使用 Using JSON 模式) 或 Headers (使用 JSON 模式) 或 Query Parameters (使用 JSON 模式) 中提供了不是有效 JSON 格式的字符串时，会报这个错误。绝大多数情况是动态构建 JSON 时表达式语法错误。
- 翔宇排错: (请详细参考前面“数据映射与表达式”部分的易错点 1 的调试技巧)
  - 核心检查点: 是否用 {{ {... } }} 包裹了整个 JSON 对象？
  - 检查 JSON 内部语法：引号、逗号、括号是否正确？
  - 检查表达式是否正确引用了数据？
  - 使用在线 JSON 校验器。
  - 简化表达式，分步测试。
SSL Error (SSL 错误，例如 certificate has expired, self signed certificate, unable to verify the first certificate)
- 原因: 你尝试连接的 HTTPS 服务器的 SSL/TLS 证书存在问题，n8n 无法验证其安全性。
- 翔宇排错:
  1. 确认 URL 正确: 确保你访问的是正确的 HTTPS 地址。
  2. 浏览器检查: 尝试用浏览器直接访问该 URL，看浏览器是否也报告证书错误。
  3. 临时忽略 (有风险): 如果你确认连接的是内部可信服务，可以临时在 “Options” 中勾选 Ignore SSL Issues 。但这会降低安全性，不应用于生产环境访问外部服务。
  4. 联系 API 提供方: 最好的解决办法是联系 API 的提供者，告知他们证书存在问题，请他们修复。
Timeout Error (超时错误，例如 ETIMEDOUT, ESOCKETTIMEDOUT, Timeout awaiting 'request' for...ms)
- 原因: n8n 在设定的超时时间 (Timeout) 内没有收到服务器的响应。这可能是因为：
  - 网络连接不稳定或缓慢。
  - API 服务器处理请求非常慢。
  - 设置的 Timeout 时间太短。
- 翔宇排错:
  1. 增加 Timeout 值: 在 “Options” 中添加 “Timeout” 选项，设置一个更长的超时时间（例如 120000 代表 2 分钟）。
  2. 检查网络: 确认 n8n 服务器的网络连接是否正常。
  3. 启用 Retry On Fail: 超时通常是临时性问题，启用自动重试可以有效解决。
  4. 联系 API 提供方: 如果某个 API 总是超时，可能需要联系提供方了解是否有性能问题。
Unsupported content type: text/html; charset=UTF-8 (不支持的内容类型)
- 原因: 你期望 API 返回 JSON 或其他特定格式的数据，但服务器实际返回了一个 HTML 页面。这通常发生在以下情况：
  - 你的请求导致了一个错误，服务器返回了一个 HTML 格式的错误页面。
  - 你的认证失效或不正确，服务器重定向到了一个 HTML 格式的登录页面。
  - 你访问的 URL 不正确，访问到了一个网页而不是 API 端点。
  - API 服务器部署在 Cloudflare 等 WAF 后面，触发了验证机制，返回了一个 HTML 验证页面。
- 翔宇排错:
  1. 检查 URL 和参数: 确认请求的 URL 和参数是否完全正确。
  2. 检查认证: 确认认证信息是否仍然有效。
  3. 开启 Include Response Headers and Status: 在 “Options” -> “Response” 中勾选此项，然后重新运行节点。查看输出中的 body 字段，看看返回的 HTML 内容到底是什么，这通常能提供关键线索。同时检查 statusCode 和 headers (特别是 Location Header，看是否有重定向)。
  4. 在浏览器中测试: 尝试在浏览器中直接访问该 URL（如果可能），看是否能复现 HTML 响应。
Referenced node is unexecuted (引用的节点未执行)
- 原因: 表达式中引用了（例如 {{ $node["节点名"]... }}）一个在当前执行路径中没有被运行的节点的数据。
- 翔宇排错: 检查工作流逻辑和连线，确保数据来源节点在当前节点之前执行，并且没有被 IF/Switch 等节点跳过。
Invalid Syntax (无效语法 – 通常指表达式)
- 原因: 你在表达式 {{ }} 中写的 JavaScript 代码本身存在语法错误。
- 翔宇排错: 仔细检查表达式的语法，例如括号是否匹配、点 . 是否用对地方、字符串引号是否闭合、函数名是否拼写正确等。使用表达式编辑器进行检查和预览。

调试方法与日志定位技巧

掌握有效的调试方法是快速解决问题的关键。

节点测试 (Test step / Run This Node): 在配置 HTTP 请求节点时，可以随时点击节点面板上的“播放”按钮（或旧版界面中的 “Test step”）。这会只运行当前这一个节点（使用来自上游节点的、当前缓存的输入数据），并显示本次运行的 Input 和 Output。这是验证节点配置是否正确、表达式是否按预期工作的最快方式。
查看执行日志 (Execution Log): 这是最重要的排错工具。当你的工作流完整运行一次后（无论是手动触发还是定时触发），你可以在 n8n 左侧边栏点击 “Executions”。找到对应的执行记录，点击进入详情。在这里，你可以看到整个工作流的执行路径，并且可以点击每一个节点，查看它在本次执行中的输入数据 (Input) 和输出数据 (Output)（或者错误信息 (Error)）。
- 翔宇日志定位技巧:
  - 从报错节点入手: 先找到报错的那个 HTTP 请求节点。
  - 看 Input: 检查它的输入数据是否是你预期的？上游节点传递过来的数据结构和值是否正确？表达式引用的字段是否存在？
  - 看 Output/Error: 如果报错了，仔细阅读 Error 信息，看是上面列出的哪种常见错误。如果没报错但结果不对，检查 Output Data 是否符合预期？如果开启了 “Include Response Headers and Status”，重点关注 statusCode, headers, body。
  - 对比差异: 如果工作流有时成功有时失败，可以对比成功和失败两次执行的日志，找出输入数据或执行环境的差异点。
  - 追溯上游: 如果发现 Input 数据就有问题，那就需要去检查上游节点的 Output，一步步往前追溯问题的根源。
使用 webhook.site 或类似服务: (前面已提及) 这是一个极其有用的技巧，用于查看 n8n 实际发出的 HTTP 请求长什么样。
1. 访问 webhook.site，它会给你一个唯一的 URL。
2. 将你的 HTTP 请求节点的 URL 临时修改为这个 webhook.site 的 URL。
3. 运行你的 n8n 节点或工作流。
4. 回到 webhook.site 页面，你就能看到 n8n 发送过来的完整请求，包括请求方法、URL、所有的请求头 (Headers)、以及请求体 (Body)。
5. 将这个实际发出的请求与 API 文档的要求进行比对，或者与你在 Postman 等工具中测试成功的请求进行比对，可以非常精确地定位到是哪个部分配置错误（例如，Header 名称不对，Body 格式错误，认证信息缺失等）。
开启 Include Response Headers and Status: (前面已提及) 在 “Options” -> “Response” 中勾选此项。获取更详细的 API 响应信息（状态码、响应头、响应体）对于判断 API 调用是否成功以及分析错误原因非常有帮助。
简化工作流和请求: 当遇到复杂问题时，尝试简化。
- 简化流程: 创建一个新的、只包含触发器和这个 HTTP 请求节点的工作流进行测试，排除其他节点的干扰。
- 简化请求: 暂时移除请求中的非必填参数（Query, Headers, Body），只保留最基本的部分，看是否能成功。如果成功，再逐步加回其他参数，找出导致问题的那个。
分步调试表达式: 如果问题出在复杂的表达式上，不要试图一次性调试整个表达式。
- 使用 Set 节点: 在 HTTP 请求节点之前加一个 Set 节点，将复杂表达式拆分成几个部分，在 Set 节点中分别计算，并将结果存入新的字段。然后让 HTTP 请求节点引用这些准备好的字段。这样可以更容易地定位是哪部分计算出错了。
- 利用预览: 在表达式编辑器中反复利用预览功能，检查每一步计算的结果。
查阅 n8n 社区和文档: 你遇到的问题，很可能别人也遇到过。尝试在 n8n 官方文档 (docs.n8n.io) 或社区论坛 (community.n8n.io) 搜索你遇到的错误信息或问题描述。社区中有大量的实战经验和解决方案分享。
利用 console.log() (进阶): 如果你需要更底层的调试信息（例如在 Code 节点中），可以使用 console.log() 将变量或调试信息打印出来。这些日志不会显示在 n8n 的 Execution Log 界面，而是会输出到运行 n8n 的后端服务器的控制台或日志文件中。你需要有访问服务器日志的权限才能看到。使用 console.log(JSON.stringify(your_object)) 可以方便地打印复杂的对象。这通常只在本地开发或有服务器访问权限时使用。

通过结合使用这些调试方法，你应该能够定位并解决大部分 HTTP 请求节点遇到的问题。记住，耐心和细致是排错的关键。

注意事项

在使用 HTTP 请求节点构建你的自动化工作流时，除了掌握配置和排错技巧外，还需要注意以下一些关键事项，以确保你的工作流稳定、安全、高效地运行。

使用注意事项

API 文档是王道 (Rule Number One!): 这点怎么强调都不为过。在你尝试使用任何一个 API 之前，必须、必须、必须仔细阅读它的官方文档。你需要从文档中了解：
- 认证方式 (Authentication): 是 API Key? OAuth 2.0? Basic Auth? Header 名称和格式是什么？
- 基础 URL (Base URL) 和端点 (Endpoints): 如何构建正确的请求 URL？
- 请求方法 (Method): 每个操作应该使用 GET, POST, PUT, PATCH, 还是 DELETE？
- 必需的请求头 (Headers): 除了认证头，是否需要设置 Content-Type, Accept 或其他自定义 Header？
- 请求参数 (Parameters): Query Parameters 和 Body Parameters 的名称、格式、是否必填、数据类型是什么？
- 响应格式 (Response Format): API 会返回什么格式的数据 (JSON, XML, Text)？成功和失败时的响应结构是怎样的？
- 错误码 (Error Codes): 不同的错误情况会返回哪些 HTTP 状态码和错误信息？
- 速率限制 (Rate Limits): 每秒/每分钟/每天允许多少次请求？超出限制会怎样？
- 分页机制 (Pagination): 如果返回列表数据，是如何进行分页的？
- 没有 API 文档？ 如果一个服务声称提供 API 但没有文档，或者文档极其简陋，那么使用它的 API 将会非常困难和不可靠，你需要谨慎考虑。
时刻牢记速率限制 (Rate Limits): 绝大多数公开 API 都有速率限制，以防止滥用和保证服务稳定。在设计工作流时，必须考虑这一点：
- 了解限制: 查阅 API 文档，明确速率限制的具体规则。
- 主动控制: 使用 HTTP 请求节点的 Batching 选项来控制请求频率。
- 被动处理: 使用 Retry On Fail 选项，在收到 429 错误时自动等待并重试（等待时间需要足够长）。
- 优化逻辑: 思考是否可以通过一次请求获取更多数据（例如，批量查询 ID 而不是逐个查询），或者是否可以降低工作流的触发频率。
- 监控: 对于关键业务流程，监控 API 调用次数和 429 错误的发生情况。
安全第一 (Security First): 处理 API 调用时，安全性至关重要：
- 绝不硬编码凭据: 再次强调，永远不要将 API Key, Secret, Token, 密码等敏感信息直接写在节点的参数里。
- 使用 n8n Credentials: 优先使用 n8n 内置的 Credentials 系统来安全地存储和管理你的凭据。
- 最小权限原则: 为 n8n 分配 API Key 或授权时，只授予它完成工作流任务所必需的最小权限。
- 警惕 Ignore SSL Issues: 避免在生产环境中使用此选项。
- 数据脱敏: 如果工作流日志可能被他人看到，注意避免在日志中（例如通过 Set 节点或 Code 节点的输出）暴露敏感的业务数据或个人信息。
健壮的错误处理 (Error Handling): 现实世界的 API 调用不总是成功的。你的工作流需要能够优雅地处理错误：
- 使用 Retry On Fail: 处理临时性错误。
- 使用 On Error (Continue using error output): 捕获无法重试的错误，将其导向错误处理分支。
- 在错误分支中: 记录错误日志、发送通知给管理员、或者根据错误类型执行备用逻辑（例如，如果主支付接口失败，尝试调用备用接口）。
- 考虑业务影响: 思考 API 调用失败对你的业务流程意味着什么，并设计相应的补偿或通知机制。
关注数据量 (Data Volume):
- 请求体大小: 某些 API 可能对单次请求的 Body 大小有限制。发送大量数据（例如上传大文件）时需要注意。
- 响应体大小: 如果 API 可能返回非常大的响应数据（例如，一个包含数万条记录的列表，或者一个很大的文件），需要考虑 n8n 服务器的内存消耗。过大的响应可能导致 n8n 进程内存溢出而崩溃。可以尝试通过查询参数限制返回的数据量，或者使用分页逐步获取。
理解幂等性 (Idempotency):
- 含义: 幂等性是指对同一个 API 操作执行一次和执行多次，产生的效果（对服务器资源的影响）是相同的。
- 常见方法的幂等性:
  - GET, HEAD, OPTIONS, DELETE 通常是幂等的。你获取一次资源和获取一百次，资源本身不会改变。你删除一次资源和尝试再删除它（如果它已经被删了），最终结果都是资源不存在。
  - PUT 通常也是幂等的。因为 PUT 是用请求体中的数据完全替换目标资源，所以执行一次和执行多次，最终资源的状态是一样的。
  - POST 通常不是幂等的。例如，每次执行创建订单的 POST 请求，通常都会创建一个新的订单。
  - PATCH 的幂等性取决于具体的操作和服务器实现。
- 为什么重要: 当你配置了 Retry On Fail 时，理解操作的幂等性很重要。如果一个非幂等的操作（如创建订单的 POST 请求）因为临时网络问题失败并自动重试成功了，你可能会重复创建订单。对于这类操作，你需要在工作流的其他地方加入逻辑来防止重复执行，或者确保 API 本身有防止重复提交的机制。

节点版本兼容性与历史演变

n8n 是一个持续发展的项目，节点的功能和界面也会不断更新。了解一些版本相关的背景有助于你更好地理解教程内容和应对可能的变化。

版本更新可能引入的问题: 尽管 n8n 团队会努力保证更新的稳定性，但在社区中偶尔也会看到用户报告在更新 n8n 版本后，之前正常工作的 HTTP 请求节点

n8n 节点版本ing (Versioning):

n8n 内部有节点版本管理机制。当你创建一个工作流并保存时，n8n 会记录下你当时使用的每个节点的版本号。

即使后续 n8n 更新了某个节点（例如，HTTP 请求节点从 V4 更新到了 V5），你之前保存的那个工作流在运行时，仍然会使用它保存时记录的旧版本节点 (V4) 。这样做是为了保证旧工作流的兼容性，避免因为节点更新而导致旧流程出错。

但是，如果你在一个新的工作流中添加 HTTP 请求节点，或者在一个旧工作流中删除旧节点后重新添加一个 HTTP 请求节点，那么你将会得到最新版本的节点。

HTTP 请求节点的演变:

存在多个版本: 随着 n8n 的发展，HTTP 请求节点也经历了几次迭代更新。你在社区的讨论或旧的教程中可能会看到提到 V1, V2, V3, V4, V4.1 等版本号。本教程聚焦的是当前最新稳定版本的节点功能和界面。虽然核心概念（Method, URL, Auth, Headers, Body）基本一致，但某些选项的名称、位置或具体行为可能在不同版本间有细微差别。

HTTP Request Tool 节点: 这是一个需要特别注意区分的概念。在 n8n 的 AI Agent 功能早期，有一个独立的、名为 “HTTP Request Tool” 的节点，专门设计用作 AI Agent 的工具。然而，在较新的 n8n 版本中，标准的 HTTP 请求节点已经可以直接作为 AI Agent 的工具来使用，并且提供了更丰富的配置（例如优化响应给 LLM 的选项）。那个旧的、独立的 “HTTP Request Tool” 节点被标记为了Legacy (遗留) 版本。

如何区分: 你可以通过打开节点配置界面来区分。如果你使用的是新版（即标准 HTTP 请求节点用作 Tool），你会看到熟悉的 “Add Option” 按钮以及用于优化响应的设置。如果你看到的是一个界面更简单、没有 “Add Option” 按钮的节点，那可能就是旧的 Legacy Tool 节点。对于新创建的 AI Agent 工作流，你应该使用标准的 HTTP 请求节点作为 Tool。

小的功能变化: 某些旧版本中存在的选项可能在新版本中被移除或改变了行为。例如，社区帖子中提到过一个 Split into items 选项，在当前版本中已经不再需要，因为节点默认就会处理并输出多个 Item 。

底层变化: n8n 的大版本更新（例如从 0.x 到 1.x）可能会带来一些底层的变化，比如对运行环境 (Docker 权限 )、数据库支持 (移除 MySQL 支持 ) 或执行模式 (废弃 EXECUTIONS_PROCESS ) 的调整。这些变化通常不会直接改变 HTTP 请求节点的核心用法，但可能会影响你的 n8n 部署和整体运行。

Make中文教程：自动化基础

小红书自动化：如何利用Make制作个人自媒体中心，批量生成爆款笔记

微信公众号图文混排文章自动化实战：利用Make 批量制作

n8n 中文教程：HTTP 请求 (HTTP Request)

教程内容简介

节点概览

节点功能定位与核心价值

输入（Input）与输出（Output）数据结构

参数与配置 (深度)

Method (方法)

URL (链接)

Authentication (认证)

Send Query Parameters (发送查询参数)

Send Headers (发送请求头)

Send Body (发送请求体)

Options (选项)

Node Settings (节点设置 – Settings Tab)

数据映射与表达式 (重点)

表达式基础语法与常用变量

在 URL, Headers, Body 中使用表达式动态构建请求

映射技巧与常见易错点

应用场景

常见报错及解决方案 (实用)

错误提示解析与排错思路

调试方法与日志定位技巧

注意事项

使用注意事项

节点版本兼容性与历史演变

翔宇工作流

相关话题

发表回复取消回复

小白也能搞懂！从零开始玩转AI大模型全指南

新手必看：用虚拟信用卡 BinGoCard 注册并使用 Google 云服务器

Make中文教程：自动化基础

小红书自动化：如何利用Make制作个人自媒体中心，批量生成爆款笔记

微信公众号图文混排文章自动化实战：利用Make 批量制作

教程内容简介

节点概览

节点功能定位与核心价值

输入（Input）与输出（Output）数据结构

参数与配置 (深度)

Method (方法)

URL (链接)

Authentication (认证)

Send Query Parameters (发送查询参数)

Send Headers (发送请求头)

Send Body (发送请求体)

Options (选项)

Node Settings (节点设置 – Settings Tab)

数据映射与表达式 (重点)

表达式基础语法与常用变量

在 URL, Headers, Body 中使用表达式动态构建请求

映射技巧与常见易错点

应用场景

常见报错及解决方案 (实用)

错误提示解析与排错思路

调试方法与日志定位技巧

注意事项

使用注意事项

节点版本兼容性与历史演变

相关话题

n8n 中文教程：AI 代理（AI Agent）

n8n 中文教程：Sort、Rename Keys、Compare Datasets、Crypto

你可能会喜欢

发表回复 取消回复

发表回复取消回复