你是不是也遇到了这种情况？
跑一个简单的自动化流程，节点转圈圈转了半分钟还没出结果；或者刚上线没几天，n8n 界面就开始变得迟钝，甚至偶尔报个 502 Bad Gateway。
作为 N8N大学 的老学长，我必须得告诉你：n8n 本身是个性能怪兽，但如果你把它当成“傻瓜式”工具来用，它就会像个没睡醒的实习生，干活磨磨蹭蹭。
性能卡顿通常不是 n8n 的锅，而是你的配置方式和架构逻辑出了问题。今天，笔者就从底层逻辑出发，给你拆解 3 个压榨性能的硬核调优思路。
思路一：给 n8n “断舍离”，清理执行历史
这是最容易被忽视，但见效最快的一步。很多新手以为 n8n 像传统软件一样，数据存着没事。错！
在 n8n 的默认配置中，每一次执行的详细数据（包括输入输出数据）都会被永久保存。当你的工作流跑了成千上万次，数据库里的数据量会膨胀到惊人的地步。查询变慢，UI 加载变慢，甚至连备份都会卡死。
调优方案：
- 调整保留策略： 在 n8n 的环境变量中设置
EXECUTIONS_DATA_PRUNE_MAX_COUNT。默认是无限大，建议改为1000或5000（根据你的磁盘和业务需求）。这意味着 n8n 只保留最近的 N 条执行记录，旧的自动归档或删除。 - 关闭调试数据： 如果不是为了排查问题，在生产环境的
.env文件中，将EXECUTIONS_DATA_SAVE_ON_SUCCESS设为false。这样只有失败的执行才会保存详细日志，能极大减少 I/O 压力。
这一招下来，你会发现数据库文件体积瞬间瘦身，界面响应速度提升 50% 以上。
思路二：告别单线程，利用队列与并发
如果你的 n8n 部署在 Docker 或者单一服务器上，默认情况下，它就像一个单核 CPU 在处理所有任务。一旦某个节点（比如耗时的 HTTP 请求或数据处理）堵住了，后面的任务就得排队。
调优方案：
我们需要引入 队列模式（Queue Mode）。这听起来很复杂，但 n8n 原生支持 Redis 作为消息中间件。
- 部署 Redis： 在 Docker Compose 中增加一个 Redis 服务（或者使用云 Redis）。
- 配置环境变量： 告诉 n8n 别自己闷头干了，把任务扔给 Redis。
EXECUTIONS_MODE=queueQUEUE_BULL_REDIS_HOST=redis(你的 Redis 地址)
- 横向扩展 Worker： 这是关键！你可以启动多个 n8n-worker 容器。Redis 负责分发任务，多个 Worker 并行处理。这就相当于从“单线程”变成了“多线程”，吞吐量成倍增长。
笔者经验： 对于高频触发的流程（比如每秒处理多条数据），队列模式是必须的，否则 n8n 进程很容易因为内存溢出（OOM）而崩溃。
思路三：逻辑层面的“外科手术”
配置调优是治标，逻辑优化才是治本。很多时候，节点卡顿是因为你在做“无用功”或者“高耗能功”。
调优方案：
1. 减少不必要的数据传输
n8n 的节点之间传递的是 JSON 对象。如果你在上游节点输出了 10MB 的数据，下游节点就得搬运 10MB。在 Set 节点或 Function 节点中，学会使用“输出”设置，只传递下游需要的字段，丢弃无用的元数据。
2. 避免在主循环中做 HTTP 请求
如果你有一个包含 1000 个项目的“循环”，并且在循环体内直接调用 HTTP Request 节点，这简直是性能杀手。
更好的做法是：使用 Split in Batches 节点控制批次大小（例如每次 50 条），或者检查 API 是否支持批量提交（Batch API）。如果必须串行请求，请确保你的网络延迟足够低，或者考虑使用异步处理逻辑。
3. 慎用 Function 节点处理大数据
JavaScript 虽然强大，但 n8n 的 Function 节点是在 Node.js 环境中运行的。如果你在其中进行复杂的双重循环或正则匹配，会阻塞整个 n8n 的事件循环。
硬核建议： 如果数据量超过 1 万条，尽量把数据处理逻辑下沉到数据库层面（使用 SQL 查询过滤），或者使用专门的 Code 节点（新版 n8n 推荐使用 Code 节点替代旧版 Function），并注意优化算法复杂度。
FAQ：关于 n8n 性能的常见疑问
Q1: 我的 n8n 运行在树莓派上，性能很差正常吗？
A: 非常正常。树莓派的 CPU 和 I/O 性能有限，尤其是 SD 卡作为存储介质时，数据库读写会成为瓶颈。建议外接 SSD，并严格限制执行历史保留数量（参考思路一）。
Q2: 更改环境变量后需要重启 n8n 吗？
A: 是的，大部分环境变量（尤其是涉及数据库和队列配置的）都需要重启 n8n 容器或服务才能生效。如果是 Docker 部署，执行 docker-compose up -d 即可。
Q3: 队列模式听起来很难，个人开发者有必要用吗？
A: 如果你的工作流每天触发次数少于 100 次，且没有特别耗时的节点，单机模式完全够用。但如果你的工作流涉及爬虫、大量数据清洗或对外部 API 的高频调用，强烈建议花点时间配置队列，这是通往生产级的必经之路。
总结与资源
性能调优不是一蹴而就的，它需要根据你的具体业务场景进行微调。核心在于三点：控制数据量（清理日志）、利用并发（队列模式）、优化逻辑（减少阻塞）。
如果你在调优过程中遇到具体的报错，或者有更进阶的优化心得，欢迎在 N8N大学 的社区交流。记住，工具是死的，人是活的，压榨出性能的上限取决于你对它的理解深度。
