基于n8n构建自动化推送工具：从零搭建可扩展的推送流水线

1. 项目概述：为什么选择 n8n 来构建自动化推送工具？

去年在 GitHub 上，一个名为 n8n 的开源项目火得一塌糊涂，Star 数蹭蹭往上涨，社区讨论也异常活跃。作为一个常年混迹在自动化工具圈的老手，我第一时间就上手试了试。结果发现，这玩意儿确实有点东西，它不像某些商业平台那样把简单问题复杂化，也不像一些老牌工具那样需要写大量代码。n8n 的核心魅力在于，它用“节点”（Nodes）和“工作流”（Workflow）这种可视化的方式，把各种应用、服务和 API 连接起来，让你像搭积木一样构建自动化流程。

那么，为什么我们要用它来做一个“自动化推送工具”呢？想象一下这些场景：你运营着一个博客，每次有新文章发布，需要同步推送到社交媒体、订阅邮件列表，甚至内部的通知群；你负责一个项目，监控着某些数据源，一旦达到阈值，就需要立刻通过钉钉、企业微信或者 Slack 通知到相关同事；或者你只是想每天定时把天气、新闻摘要、待办事项汇总成一条消息，推送到自己的手机上。这些重复、琐碎但又必须及时准确的任务，正是自动化推送工具的用武之地。传统做法要么需要对接多个平台的 API，写一堆脚本，维护起来头疼；要么就得购买集成度高的 SaaS 服务，价格不菲且灵活性受限。

n8n 的出现，完美地解决了这个痛点。它内置了海量的节点，覆盖了从 HTTP 请求、数据库操作，到 GitHub、GitLab、Google Sheets、Telegram、钉钉、企业微信等数百种常见服务。你几乎不需要写代码，通过拖拽和配置就能完成复杂的逻辑编排。更重要的是，它是开源的，你可以自己部署，完全掌控数据和流程，这对于注重数据隐私和定制化的团队或个人来说，吸引力巨大。这个项目，就是带你从零开始，利用 n8n 快速搭建一个高度定制化、可扩展的自动化推送工具，无论是技术爱好者、运营人员还是开发者，都能从中找到适合自己的玩法。

2. 核心设计思路：像搭积木一样构建推送流水线

在动手之前，我们先要把整个工具的骨架搭起来。一个自动化推送工具，无论推送内容是什么，目标平台是谁，其核心逻辑都可以抽象为一个清晰的流水线：触发 → 获取/处理数据 → 判断决策 → 格式化消息 → 执行推送。n8n 的工作流设计哲学，与这个流水线模型天然契合。

2.1 工作流的核心逻辑拆解

我的设计思路是模块化的，每个环节对应 n8n 中的一个或多个节点：

1. 触发层（Trigger）：决定工作流何时启动。这可以是定时任务（如每天上午9点）、Webhook 调用（接收外部系统的通知）、轮询（定期检查某个 RSS 源或 API 接口），甚至是手动点击运行。n8n 的Schedule Trigger和Webhook节点在这里是主力。

2. 数据源层（Data Source）：获取需要推送的原始数据。这可能来自一个公开 API（如天气、股价）、一个数据库查询、一个 RSS 订阅源、一个 Google Sheets 表格，或者监听 GitHub 仓库的新提交。我们会用到HTTP Request、RSS Feed Read、MySQL等节点。

3. 处理与决策层（Process & Decide）：原始数据往往不能直接使用。这里需要进行清洗、过滤、转换，并根据内容做出决策。例如，只推送包含特定关键词的新闻；或者当监控的服务器 CPU 超过 80% 时才发送告警。Function节点（写点 JavaScript 代码）、IF节点、Filter节点将在这里大显身手。

4. 消息格式化层（Format）：将处理好的数据，包装成目标平台所需的格式。推送到钉钉、飞书、企业微信的消息体结构各不相同；邮件需要主题和正文；短信则有字数限制。Set节点可以用来组装数据，Function节点也可以进行复杂的模板渲染。

5. 推送执行层（Action）：调用最终平台的 API，将消息发送出去。n8n 为许多主流平台提供了现成的节点，如Telegram、Slack、Email (SMTP)，以及针对国内环境的DingTalk、WeChat Work等。如果没有现成节点，万能的HTTP Request节点可以调用任何 RESTful API。

这个流水线思路的好处是清晰、可复用。你可以轻松替换其中任何一个环节。比如，把数据源从 RSS 换成数据库，或者把推送目标从 Slack 换成钉钉，而无需重写整个流程。

2.2 为什么 n8n 是更优解？

市面上自动化工具不少，Zapier、Integromat（现 Make）都是佼佼者。但 n8n 在构建此类工具时，有几个独特优势：

• 开源与自托管：数据完全掌握在自己手中，这对于处理内部信息或敏感数据至关重要。你可以在自己的服务器上部署，无需担心服务商的定价策略变更或服务中断。
• 强大的逻辑处理能力：内置的Function节点允许你插入 JavaScript/TypeScript 代码，这意味着几乎无限的处理能力。你可以进行复杂的数据计算、字符串操作，甚至调用 Node.js 模块（需在自托管环境中安装）。
• 极高的灵活性：HTTP Request节点让你可以连接任何具有 API 的服务，无论 n8n 是否为其提供了官方节点。这使得它能够适应各种长尾、小众或内部系统。
• 可视化调试：每个节点运行后，你都可以点击查看其输入和输出数据，这比在日志文件中翻找错误信息直观得多，极大降低了调试门槛。

注意：对于国内用户，访问 GitHub 获取 n8n 或相关资源可能遇到网络延迟问题。一个常见的实践是使用可靠的镜像源来加速克隆仓库或下载依赖。例如，在克隆 n8n 仓库时，可以将github.com替换为hub.fastgit.org等镜像地址（请注意镜像源的可用性可能随时间变化）。这纯粹是为了提升下载效率，与任何其他网络访问方式无关。

3. 环境准备与 n8n 部署实战

理论讲完了，我们开始动手。首先得把 n8n 跑起来。部署方式多种多样，这里我推荐两种最实用、最快捷的方式：Docker 和直接 npm 安装。我会详细说明步骤和背后的考量。

3.1 部署方案选择：Docker 还是 npm？

• Docker 部署（推荐用于生产或长期使用）：
  • 优点：环境隔离，一键启动，易于管理和迁移。特别是使用docker-compose，可以轻松配置数据库、持久化存储等。
  • 缺点：需要本地安装 Docker 和 Docker Compose，对初学者可能多一个学习步骤。
• npm 直接安装（推荐用于快速体验和开发）：
  • 优点：最简单，一条命令即可。适合在个人电脑上快速搭建测试环境。
  • 缺点：环境依赖与系统耦合，长期运行管理不如 Docker 方便。

考虑到我们这个工具可能会长期运行并处理重要任务，我强烈建议使用Docker Compose部署，它能一劳永逸地解决环境问题。下面是我的docker-compose.yml文件配置，它包含了 n8n 和 PostgreSQL 数据库（生产环境建议使用外部数据库，如云数据库服务）。

version: '3.8' services: n8n: image: n8nio/n8n container_name: n8n restart: unless-stopped ports: - "5678:5678" # n8n 默认端口 environment: - N8N_PROTOCOL=http - N8N_HOST=localhost # 根据实际情况修改，如果是服务器部署，可改为服务器IP或域名 - N8N_PORT=5678 - N8N_WEBHOOK_URL=http://localhost:5678/ # Webhook 回调地址，同上需修改 - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=postgres - DB_POSTGRESDB_PORT=5432 - DB_POSTGRESDB_DATABASE=n8n - DB_POSTGRESDB_USER=n8n - DB_POSTGRESDB_PASSWORD=your_secure_password_here # 务必修改为强密码！ - N8N_ENCRYPTION_KEY=your_encryption_key_here # 用于加密凭证，务必修改并妥善保管！ - GENERIC_TIMEZONE=Asia/Shanghai # 设置时区为上海 volumes: - n8n_data:/home/node/.n8n # 持久化存储工作流、配置等 depends_on: - postgres networks: - n8n_network postgres: image: postgres:15-alpine container_name: n8n_postgres restart: unless-stopped environment: - POSTGRES_USER=n8n - POSTGRES_PASSWORD=your_secure_password_here # 与上面保持一致 - POSTGRES_DB=n8n volumes: - postgres_data:/var/lib/postgresql/data networks: - n8n_network volumes: n8n_data: postgres_data: networks: n8n_network: driver: bridge

关键配置解析与实操要点：

1. 密码与密钥：DB_POSTGRESDB_PASSWORD和N8N_ENCRYPTION_KEY必须替换为你自己生成的强密码和密钥。后者用于加密保存在数据库中的第三方服务凭证（如 API Token），至关重要。可以用命令openssl rand -base64 24快速生成一个。
2. 网络与端口：ports映射将容器内的 5678 端口暴露到宿主机的 5678 端口。确保宿主机该端口未被占用。如果部署在云服务器，需要在安全组/防火墙中开放此端口。
3. 持久化存储：volumes配置确保了即使容器删除，你的工作流数据和数据库文件也不会丢失。
4. 时区：GENERIC_TIMEZONE设置为Asia/Shanghai，这能保证定时任务等基于时间的操作按照东八区时间执行，避免混乱。

保存这个文件为docker-compose.yml，然后在同一目录下执行docker-compose up -d，等待片刻，访问http://你的服务器IP:5678就能看到 n8n 的登录界面了。首次登录需要创建管理员账户。

3.2 基础配置与界面熟悉

首次登录后，建议先进行几项基础配置：

• 用户管理：在设置中，可以添加其他用户并分配角色（所有者、成员等）。
• 外部存储（可选但推荐）：在“设置” -> “外部存储”中，可以配置对象存储（如 AWS S3、MinIO）来保存 n8n 执行过程中产生的二进制文件（如图片、附件），避免占用容器本地空间。
• 环境变量：对于需要频繁使用但又不想硬编码在工作流中的值（如 API 的基础 URL、通用 Token），可以在“设置” -> “环境变量”中定义，然后在工作流中用{{ $env.VARIABLE_NAME }}引用。

花几分钟时间熟悉界面：左侧是节点列表，按功能分类；中间是画布，用于拖拽构建工作流；右侧是节点的详细配置面板和测试/执行面板。

4. 构建第一个自动化推送工作流：GitHub 仓库动态监控

现在我们用实际案例来串联整个流水线。假设我们要监控一个指定的 GitHub 仓库，当有新的 Issue 被创建时，自动推送通知到钉钉群。

4.1 工作流蓝图设计

这个工作流的逻辑链如下：

1. 触发：每 5 分钟检查一次指定仓库。
2. 数据获取：调用 GitHub API 获取最新的 Issues 列表。
3. 决策判断：对比上一次检查的结果，筛选出本次新增的 Issue。
4. 消息格式化：将新增 Issue 的标题、链接、创建者等信息格式化成钉钉消息要求的 Markdown 格式。
5. 推送执行：调用钉钉群机器人的 Webhook，发送消息。

4.2 分步实现与节点配置

第一步：设置 Schedule Trigger从左侧节点列表的 “Trigger” 分类下，拖拽一个Schedule Trigger节点到画布。配置它每 5 分钟运行一次（Cron 表达式：*/5 * * * *）。这个节点是整个工作流的起点。

第二步：获取 GitHub Issues拖拽一个HTTP Request节点连接到 Schedule Trigger 之后。

• 方法：GET
• URL：https://api.github.com/repos/{owner}/{repo}/issues。将{owner}和{repo}替换为你要监控的仓库，例如n8n-io/n8n。
• 查询参数：可以添加state=open、sort=created、direction=desc等来过滤和排序。
• 认证：在“Authentication”下拉选择“Generic Credential Type”，类型选“Header Auth”。在“Name”填Authorization，在“Value”填token YOUR_GITHUB_PERSONAL_ACCESS_TOKEN。你需要先在 GitHub 上生成一个 PAT（Settings -> Developer settings -> Personal access tokens -> Tokens (classic)），并赋予repo权限（如果是公开库，有时可以不用 Token，但有速率限制）。

第三步：判断是否有新 Issue（核心逻辑）这是关键的一步。我们需要记住上一次检查时看到的 Issue ID，并与本次结果对比。

1. 存储上一次的 ID：使用Set节点。在第一次执行后，我们需要将获取到的 Issue 列表中的第一个（最新）Issue 的id存储到一个变量中，供下次比较。但这里有个问题：工作流每次执行都是独立的。我们需要一个跨执行持久化的存储。n8n 提供了Binary/Text File节点（读写本地文件）或更常用的Function节点配合全局变量（但重启会丢失）。对于生产环境，更可靠的做法是使用一个简单的键值数据库，比如用HTTP Request节点调用一个云数据库的 API，或者使用 n8n 专业版/企业版的功能。为了简化演示，我们采用一个“模拟”策略：假设我们只关心“过去5分钟内”创建的 Issue。这样我们只需要在每次请求 API 时，传入since参数，值为5分钟前的时间戳即可。
2. 优化 HTTP Request：回到上一步的 HTTP Request 节点，添加一个查询参数：since。它的值需要动态计算。我们可以点击输入框旁边的“表达式”图标（</>），输入：

   {{ new Date(Date.now() - 5*60*1000).toISOString() }}

   这个表达式会生成一个5分钟前的 ISO 格式时间字符串。这样，GitHub API 只会返回这个时间之后创建或更新的 Issue。

第四步：格式化钉钉消息拖拽一个Function节点。

• 这个节点接收上一步 HTTP Request 返回的 Issues 数组。
• 我们需要编写 JavaScript 代码，将数组中的每个 Issue 对象，转换成钉钉机器人所需的 Markdown 文本。代码示例如下：

  // items 是输入数据，包含了 GitHub API 的响应 const issues = items[0].json; if (!issues || issues.length === 0) { // 如果没有新 Issue，可以返回空数组，后续节点将不会执行 return []; } const dingtalkMessages = issues.map(issue => { // 构建 Markdown 内容 const markdownText = `### 🚨 仓库有新 Issue！\n\n` + `**标题**：${issue.title}\n\n` + `**创建者**：${issue.user.login}\n\n` + `**链接**：[点击查看](${issue.html_url})\n\n` + `**创建时间**：${new Date(issue.created_at).toLocaleString('zh-CN')}`; return { json: { msgtype: 'markdown', markdown: { title: `New Issue: ${issue.title.substring(0, 30)}...`, text: markdownText }, at: { // 可以 @ 特定人或所有人 isAtAll: false // 设为 true 则 @所有人 } } }; }); // 返回一个数组，每个元素对应一条要发送的钉钉消息 return dingtalkMessages;

第五步：推送到钉钉拖拽另一个HTTP Request节点连接到 Function 节点之后。

• 方法：POST
• URL：你的钉钉群机器人的 Webhook 地址。需要在钉钉群里添加一个自定义机器人来获取。
• Headers：Content-Type: application/json
• Body：选择“JSON”，然后点击表达式图标（</>），输入{{ $json }}。这样就会将上一个 Function 节点输出的 JSON 对象直接作为请求体发送。

第六步：测试与激活点击右上角的“执行工作流”按钮（播放图标），选择“从第一个节点开始执行”。你可以在每个节点上点击，查看其输入和输出数据，确保每一步都符合预期。测试成功后，点击画布上方的“激活”开关，工作流就会按照 Schedule Trigger 的设置定时运行了。

实操心得：在 Function 节点中，items是一个数组，其结构取决于上游节点连接的数量和方式。通常，如果上游只有一个节点，items[0].json就是该节点的输出数据。理解这个数据结构是编写正确代码的关键。多使用节点右侧的“测试步骤”功能，查看实际的数据形状。

5. 进阶技巧与复杂场景实现

基础流程跑通后，我们可以玩点更花的，让推送工具更智能、更强大。

5.1 多平台同步推送与消息路由

一个事件往往需要通知到多个地方。比如，严重的服务器告警需要同时推送到钉钉群、发邮件给负责人、并在 Slack 的运维频道广播。在 n8n 里实现这个非常简单，有两种主流模式：

• 并行推送：在消息格式化节点（如 Function）之后，将输出同时连接到多个推送节点（钉钉 HTTP Request、Email 节点、Slack 节点）。n8n 会复制数据流，并行执行这些分支。配置简单，但无法针对不同平台定制消息格式。
• 串行定制推送：更推荐的方式。在 Function 节点生成一个包含所有信息的“富数据”对象，然后分别连接多个Function或Set节点，每个节点专门为其中一个目标平台（如钉钉、邮件）提取和格式化所需的数据，再连接各自的推送节点。这样可以对每个平台进行精细化定制。

消息路由示例：假设我们监控错误日志，根据错误级别决定推送渠道。

1. HTTP Request 获取日志。
2. Function 节点分析日志，为每条日志添加一个level字段（如 “ERROR”, “WARN”, “INFO”）。
3. 使用IF节点进行路由：
   • 条件1：{{ $json.level === "ERROR" }}-> 连接到“钉钉告警”分支。
   • 条件2：{{ $json.level === "WARN" }}-> 连接到“Slack 通知”分支。
   • 否则 -> 可以连接到“数据库存档”分支或直接结束。

5.2 使用队列与错误处理提升可靠性

当推送量变大或目标 API 不稳定时，需要考虑可靠性。

• 利用 n8n 的“错误触发”机制：任何节点配置面板底部都有一个“错误触发”选项。勾选后，当该节点执行出错时，流程不会直接停止，而是会将错误信息传递给后续连接的节点。你可以连接一个Function节点来记录错误（例如，发送到另一个监控通道），或者连接一个Wait节点，等待一段时间后重试。
• 模拟队列处理：对于需要顺序处理或防止并发的任务，可以使用Wait节点。例如，在推送节点前加一个 Wait 节点，设置随机等待 1-3 秒，可以稍微错开请求，避免对目标 API 造成瞬时压力。对于更复杂的队列，可以引入外部消息队列（如 Redis、RabbitMQ），n8n 通过 HTTP Request 节点与之交互。
• 设置超时与重试：在 HTTP Request 节点的“Options”选项卡中，可以设置请求超时时间。对于不稳定的网络或 API，适当调高超时或配合错误触发进行重试是必要的。

5.3 集成数据库实现状态记忆

我们之前用“过去5分钟”的策略来模拟新数据检测，这有其局限性（比如如果工作流停了6分钟，就会漏掉一条）。更健壮的方法是使用数据库记录上一次处理到的 ID 或时间戳。

1. 准备数据库：可以使用 n8n 内置的 PostgreSQL（如果用了上面的 docker-compose），或者任何其他 n8n 支持的数据库（如 MySQL、SQLite）。
2. 工作流改造：
   • 开始时：第一个节点使用MySQL（或对应数据库）节点，执行一个查询，获取上次记录的last_processed_id或last_processed_time。
   • 获取数据：HTTP Request 节点调用 API，使用上一步查询到的时间戳作为since参数。
   • 处理数据：Function 节点处理新数据。
   • 更新状态：在处理完数据后，使用另一个MySQL节点，执行 UPDATE 语句，将最新的 ID 或时间戳写回数据库。

这样，无论工作流间隔多久运行，都能准确地获取自上次成功处理以来的所有新数据。

6. 性能调优、安全与部署最佳实践

当你的自动化推送工具承担起关键业务时，稳定性、安全性和性能就变得尤为重要。

6.1 工作流性能优化

• 减少不必要的 API 调用：仔细设计 Schedule Trigger 的频率。不是越频繁越好。结合业务实际，5分钟、15分钟、1小时可能都是合理的选择。对于 Webhook 触发的方式，则没有这个问题。
• 启用缓存：对于某些不常变化但又需要频繁读取的配置数据（如部门映射表），可以在工作流开始时用一个HTTP Request或Function节点获取并存储在 n8n 的“静态数据”中（通过变量），避免每次执行都去查询。
• 批量处理：如果一次可能获取大量数据（如100条日志），不要用Split In Batches节点一条条地推，这会产生大量 HTTP 请求。尽量在推送节点（如钉钉机器人）支持的情况下，将多条信息合并为一条摘要消息发送，或者利用平台的消息卡片功能展示列表。
• 关注节点执行细节：在 n8n 设置中，可以调整“执行数据”的保留策略。默认会保留所有节点的输入输出数据用于调试，但这会占用大量数据库空间。对于稳定运行的生产工作流，可以考虑关闭此功能或缩短保留时间。

6.2 安全加固要点

• 凭证管理：永远不要将 API Token、密码等敏感信息硬编码在工作流 JSON 或节点配置里。务必使用 n8n 的Credentials功能。在需要认证的节点（如 HTTP Request），选择“Create New Credential”，选择类型并填写信息。这些凭证会被加密后存储在数据库中。在团队协作时，可以安全地共享工作流而不泄露密码。
• 访问控制：为 n8n 实例设置强密码，并合理分配用户角色。非管理员用户不应有权限修改关键工作流或查看包含敏感信息的工作流数据。
• 网络隔离：将 n8n 部署在内网，仅通过反向代理（如 Nginx）暴露必要的端口（Web UI 和 Webhook 端口）。为 Webhook 端点设置额外的认证（如 Token 验证），防止被恶意调用。
• 审计日志：n8n 企业版提供了更详细的审计日志功能。社区版可以通过将重要操作（如工作流激活/停用、错误信息）通过一个特定的“审计日志推送”工作流发送到安全日志平台来实现简易审计。

6.3 生产环境部署建议

1. 使用进程管理工具：即使使用 Docker，也建议在宿主机上使用systemd或supervisor来管理docker-compose进程，确保容器在异常退出或服务器重启后能自动恢复。
2. 分离数据库：对于正式项目，不要使用与 n8n 同容器的数据库。应该使用一个独立的、有备份策略的 PostgreSQL 或 MySQL 实例（可以是云服务商的 RDS）。
3. 配置反向代理与 HTTPS：使用 Nginx 或 Caddy 作为反向代理，为 n8n 的 Web 界面和 Webhook 地址配置 HTTPS（使用 Let‘s Encrypt 免费证书）。这能加密通信，保护凭证和数据。
4. 资源监控：监控 n8n 所在服务器的 CPU、内存、磁盘使用情况。监控 n8n 日志（Docker 日志可通过docker-compose logs -f n8n查看），关注错误信息。
5. 备份策略：定期备份两部分数据：一是 n8n 的数据库（包含工作流定义、执行历史、凭证）；二是 n8n 的存储卷（如果使用了文件存储）。可以将备份脚本做成另一个 n8n 工作流，定时执行并上传到云存储。

7. 常见问题排查与调试技巧实录

在实际操作中，你肯定会遇到各种问题。下面是我踩过的一些坑和解决方法，希望能帮你快速排雷。

7.1 工作流执行不触发或频率不对

• 检查 Schedule Trigger 的时区：这是最常见的问题。确保在 n8n 的环境变量中设置了GENERIC_TIMEZONE（如Asia/Shanghai），并且 Schedule Trigger 节点配置中的时区与之匹配。有时候节点配置会覆盖全局设置，最好两边都确认一下。
• 检查工作流是否激活：画布上方的开关必须是绿色的“已激活”状态。
• 查看执行列表：在左侧菜单“执行列表”中，可以看到所有工作流的历史执行记录、状态（成功/失败）和开始时间。从这里可以最直观地判断是否按计划执行。

7.2 HTTP 请求节点报错（4xx/5xx）

• 认证失败 (401/403)：检查使用的 Credential 是否正确，Token 是否过期，是否有足够的权限。对于 GitHub PAT，确保 scope 勾选了repo（私有库）或public_repo。
• 速率限制 (429)：很多 API 都有调用频率限制。解决方案：
  1. 降低 Schedule Trigger 的频率。
  2. 在 HTTP Request 节点的“Options”中，启用“Retry On Fail”并设置重试间隔和最大重试次数，让它优雅地等待后重试。
  3. 如果请求量确实大，需要申请更高的 API 限额或使用企业版 API。
• 目标服务不可用 (502/503/504)：可能是对方服务器问题或网络临时问题。同样，启用重试机制。如果是自建服务，检查服务状态和网络连通性。

7.3 Function 节点代码错误

• “items is not defined” 或 “Cannot read property ‘json’ of undefined”：这通常是因为上游节点没有输出数据，或者输出数据的结构与你的代码预期不符。务必使用“测试步骤”功能，先手动运行到出错节点的上一个节点，查看其输出的items具体是什么结构。你的代码需要根据这个实际结构来编写。
• 语法错误：Function 节点使用的是 JavaScript/TypeScript。注意检查括号、引号是否匹配，变量名是否拼写正确。可以使用console.log()输出调试信息，这些日志会在节点执行详情中看到。
• 异步操作：Function 节点内不支持async/await或直接返回 Promise。如果你需要进行异步操作（如调用另一个 API），目前必须使用HTTP Request等异步节点，或者将逻辑拆分成多个节点。

7.4 钉钉/飞书等消息发送成功但格式错乱

• Markdown 语法兼容性：钉钉、飞书、企业微信的 Markdown 语法是标准语法的子集或变体，并非完全兼容。常见的坑：
  • 表格支持可能较弱，尽量使用简单的列表。
  • 图片链接可能需要特定的格式或需要先上传到企业素材库。
  • 标题符号#后必须跟空格，否则不识别。
• 消息长度限制：各平台对单条消息的长度都有限制（如钉钉 Markdown 消息正文上限约 5000 字符）。如果推送内容过长，需要在 Function 节点中进行截断或拆分。
• @ 某人失败：确保在消息体中正确设置了at字段，并且atMobiles或atUserIds填写的是正确的手机号或用户ID（取决于机器人类型）。有时需要在钉钉机器人设置中开启“加签”安全设置，并在 Webhook URL 后附加签名参数。

7.5 数据库节点连接失败

• 连接超时：检查数据库地址、端口、防火墙设置是否正确。在 Docker 环境中，确保 n8n 容器和数据库容器在同一个 Docker 网络内，并且使用容器名作为主机名（如上面配置中的postgres）。
• 认证失败：仔细检查用户名、密码和数据库名。在 PostgreSQL 中，有时需要指定默认的postgres数据库进行初始连接。
• SSL 问题：某些云数据库强制要求 SSL 连接。在 n8n 的数据库节点配置中，可能需要勾选“SSL”选项并提供相关证书。

调试心法：遇到问题，遵循“从前往后，逐层排查”的原则。激活工作流的“手动执行”模式，从第一个节点开始，逐个节点点击“执行节点”，观察每个节点的输入和输出数据，就像调试程序一样设置“断点”。绝大多数问题都能通过这个方法定位到具体的节点和错误信息。n8n 的这个可视化调试能力，是其相比于纯代码方案最大的优势之一。