大家好，我是 N8N大学 的主编。
最近在社区里，我发现很多兄弟的 n8n 工作流跑起来像放幻灯片，一个任务节点转半天，甚至直接卡死无响应。看着那个转圈的 loading 图标，血压是不是瞬间就上来了？
别急，这在 n8n 的使用中太常见了。很多时候并不是 n8n 本身不行，而是我们在设计工作流时，不知不觉踩了性能的坑。今天，笔者就带大家硬核拆解一下，你的 n8n 工作流到底卡在了哪里。
1. 真相揭秘：n8n 到底卡在哪？
首先我们要明白 n8n 的运行机制。n8n 的核心是一个 Node.js 进程，它负责调度任务、执行节点逻辑、存储数据。如果你的工作流是“单线程”执行的，那么所有节点都会挤在这个进程里排队。
根据我们 N8N大学 的经验，性能瓶颈通常集中在以下三个环节：
- 数据吞吐量过大：也就是“传参”太多。
- 阻塞式 I/O：同步等待外部 API 响应。
- 资源限制：服务器配置太低，内存或 CPU 跑满。
2. 头号杀手：数据传输与内存溢出
这是新手最容易犯的错误。很多兄弟喜欢把前一个节点的所有数据（Binary 或 JSON）原封不动地传给下一个节点。
想象一下，你通过 HTTP Request 下载了一个 5MB 的文件，或者通过 Google Sheets 读取了 1000 行数据。如果你不加处理，直接把这些数据塞进下一个节点，n8n 的内存占用就会瞬间飙升。
症状： 工作流运行几秒后突然崩溃，或者日志报 JavaScript out of memory。
解决方案：使用 Set 节点“瘦身”
在两个耗时的节点之间，插入一个 Set 节点（或者使用 Item Lists 节点）。
不要传递完整的 Binary 数据或庞大的 JSON 对象。如果你只需要文件的 URL，就只保留 URL 字段；如果你只需要表格里的某几列，就只保留那几列。
笔者建议： 永远假设你的工作流会处理海量数据，尽早养成“只传必要数据”的习惯。这能直接避免 80% 的内存溢出问题。
3. 网络延迟：最隐蔽的“等待”
n8n 的节点默认是顺序执行的。这意味着，如果节点 A 是一个 HTTP Request，它必须等外部 API 返回数据后，节点 B 才会启动。
如果你的外部 API 响应很慢（比如 10 秒），你的工作流就会每一步都卡顿 10 秒。如果你有 10 个这样的请求，总耗时就是 100 秒！这看起来就像程序卡死了一样。
解决方案：异步处理与 Webhook
对于耗时的外部请求（如大文件生成、复杂计算），不要让 n8n 原地等待。
- Webhook 策略： 让外部系统处理完任务后，通过 Webhook 回调通知 n8n。n8n 收到回调再触发后续流程。
- 轮询优化： 如果必须轮询，设置合理的间隔时间，不要让 n8n 疯狂发送请求。
4. 数据库与查询瓶颈
当 n8n 连接数据库（如 MySQL, PostgreSQL）或读写 Google Sheets 时，如果查询语句写得不好，或者数据量太大，会直接拖垮整个工作流。
很多兄弟在 Postgres 或 MySQL 节点中使用 SELECT * FROM table，却忘了加 LIMIT。n8n 会一次性把表里的几万条数据加载到内存里，瞬间卡死。
解决方案：分页查询与索引
在数据库节点中，务必使用 LIMIT 和 OFFSET 进行分页读取。虽然 n8n 有“分页”选项，但写 SQL 时的约束更靠谱。
另外，确保你查询的字段加了索引。没有索引的全表扫描在数据量大时是灾难性的。
5. 节点配置错误：循环的噩梦
在 n8n 中，如果两个节点形成了数据闭环，或者在 Split in Batches 节点中配置不当，会导致死循环。
笔者见过最离谱的案例是：一个工作流每处理一条数据就往队列里写一条新数据，导致队列无限膨胀，n8n 进程直接卡死。
如何排查循环问题？
检查你的 Split in Batches 节点。它的参数 Batch Size（批次大小）和 Wait Time（等待时间）非常重要。
如果你的批次设置过小，而等待时间为 0，n8n 会在极短时间内处理大量批次，导致 CPU 飙升。适当调大批次大小，增加微小的等待时间，能有效缓解 CPU 压力。
6. 服务器配置：硬件的锅？
有时候，真的就是机器不行。
n8n 对 CPU 的单核性能比较敏感，对内存要求较高。如果你在 1核 1G 的 VPS 上跑复杂的 n8n 工作流，卡顿是必然的。
最低配置建议：
- 测试环境：2核 2G
- 生产环境：4核 8G（如果涉及大量数据处理）
如果你使用的是 Docker 部署，记得检查 Docker 的内存限制。默认情况下，Docker 可能会限制容器的内存使用，导致 n8n 频繁重启。
7. 常见 FAQ 避坑指南
Q1: 为什么我的 Webhook 触发后，工作流要等很久才开始执行？
A: 这通常不是卡顿，而是 n8n 的队列处理机制。如果你的 n8n 实例处于高负载状态，Webhook 会进入队列排队。检查 Executions 页面，看看是否有大量“等待中”的任务。
Q2: 如何判断是节点慢还是 n8n 慢？
A: 打开 n8n 的执行日志（Execution Log）。点击每个节点查看耗时。如果某个节点（如 HTTP Request）耗时极长，那就是外部 API 的问题；如果所有节点都极快但整体很慢，可能是 n8n 本身的资源瓶颈。
Q3: 升级 n8n 版本能解决性能问题吗？
A: 有可能。n8n 团队在不断优化核心引擎和节点逻辑。例如，新版本对二进制数据的流式处理更好。但如果是工作流设计逻辑问题，升级通常治标不治本。
总结与资源
n8n 工作流卡顿，核心在于数据量与处理能力的不匹配。
作为 N8N大学 的主编，我建议大家在设计工作流时，遵循“小步快跑”的原则：先让流程跑通，再逐步增加数据量，并配合 Set 节点控制数据传输，最后才是考虑服务器扩容。
如果你还想深入学习 n8n 的性能调优，欢迎访问 N8N大学官网，这里有更多硬核的实战教程等你。
