Make.com 到 n8n：高容量工作流技术迁移指南

Source: Dev.to

操作数学问题

Make 按 操作 收费——每一步、分支和迭代都单独计数。
示例：对 5 000 行数据集进行三条条件分支过滤，单次执行会产生 15 000 次操作。

n8n 按执行次数（或自托管计算）计费。同一工作流作为 一次执行 运行，在 2 核 VPS 上约耗时 0.3 秒。

成本对比

经济性显而易见；迁移工作量才是变量。

认证：真正的锁定

Make 将 OAuth 令牌存放在其基础设施中，因此迁移时需要对每个服务重新认证。对 12 家客户的 47 条工作流来说，这耗时 18 小时 的专注工作。

n8n 使用 credentials.json 文件，让你完全拥有令牌。导出、加密、迁移——不再受供应商“人质”局限。

迁移策略

• 审计 – 导出 Make 场景蓝图（JSON）以作参考。
• 映射 – n8n 节点并非 1:1 对应。Make 的 Iterator 需要映射为 n8n 的 Split In Batches 或原生循环功能。
• 重建 – 先从 webhook 触发器开始，然后使用 Code 节点重建逻辑，以处理复杂的 JSON 操作。

关键技术差异

Webhook

• Make：即时 webhook，但会被排队并受速率限制。
• n8n：原始 HTTP 端点；在 $12 实例上可处理 400 请求/分钟，且不会排队。

错误处理

Make 的可视化错误路由往往变成纠结的“意大利面”。n8n 提供编程式处理，具备 “Continue On Fail” 与 Execute Once 节点。

{
  "nodes": [
    {
      "parameters": {
        "continueOnFail": true
      },
      "name": "Risky API Call",
      "type": "n8n-nodes-base.httpRequest"
    }
  ]
}

数据转换

Make 的沙箱函数速度慢。n8n 的 Code 节点直接运行原生 JavaScript。

• Make：对 10 000 行数组的转换需 45 秒（常常超时）。
• n8n：同样任务仅需 0.8 秒。

性能基准

相同工作流复杂度（通过 API 进行 CRM 丰富化）：

• Make（Team 计划）：平均执行 4.2 秒，约 100 并发运行后出现限流。
• n8n（Docker 在 CPX21 上）：平均执行 0.7 秒，能处理 500 并发运行且无性能下降。

生产环境 Docker Compose

version: '3'
services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - EXECUTIONS_MODE=regular
      - N8N_LOG_LEVEL=warning
    volumes:
      - ~/.n8n:/home/node/.n8n
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 4G

隐形成本：调试

Make 的可视化调试器要求你逐步点击每个节点。凌晨 2 点的客户 webhook 失效可能需要 40 次点击才能定位错误。

n8n 的执行日志在每个节点展示完整的 JSON 负载，将故障工作流的平均解决时间从 45 分钟 降至 8 分钟。

何时继续使用 Make

如果你只是在内部构建简单的 “Zap‑style” 自动化（< 1 k 次操作/月），迁移成本可能不划算。Make 的可视化构建器对 MVP 来说非常快捷。

当你需要：

• 处理大批量数据
• 向客户转售自动化服务
• 实现自定义错误处理
• 克服速率限制

时，考虑使用 n8n。自托管的 n8n 不仅更便宜，还能解锁更高的能力层级。

我已完整记录了迁移清单——包括认证迁移脚本和 Docker 配置——可在工作流捆绑包中获取，地址为 whop.com/jbhflow/。