大家好，我是 N8N大学 的首席主编。做自动化这么多年，最怕听到的词不是“需求变更”，而是“跑不动了”。
尤其是当你兴致勃勃地设计了一个复杂的并行处理工作流，比如批量抓取数据、同时处理成千上万条订单，结果 n8n 刚启动没多久，整个服务直接卡死，甚至直接 OOM（Out of Memory）崩溃。这种体验，就像你开着一辆五菱宏光去拉货，结果装的全是钢筋水泥——发动机直接冒烟了。
今天，笔者就带大家硬核拆解一下 n8n 并行任务跑崩的底层原因，并分享一套实战排查与优化的完整记录。这不是理论课，这是手术刀式的实战指南。
为什么并行任务会把 n8n 跑崩？
很多新手以为 n8n 是“无限性能”的，毕竟它是基于 Node.js 构建的。但现实是残酷的：n8n 的核心引擎是单线程的（Node.js 事件循环），而所谓的“并行”通常依赖于 Loop Over Items 节点配合 Wait 或 Split in Batches 节点。
当你设置 Wait 节点的并发量过大（例如瞬间发起 1000 个 HTTP 请求），或者在 Code 节点中处理巨大的 JSON 数据集时，内存占用会呈指数级飙升。Node.js 的内存管理机制决定了它无法像 Java 那样通过简单的堆内存扩容来解决所有问题，一旦触及 V8 引擎的默认堆内存上限（通常在 512MB - 1.5GB 之间，取决于环境），进程就会直接崩溃。
实战排查：三步定位内存杀手
不要盲目重启服务，我们需要像侦探一样找到那个“吃内存”的元凶。
第一步：检查工作流设计逻辑
这是最容易被忽视的软问题。请打开你的 n8n 工作流，重点检查以下节点：
- Loop Over Items：如果你的输入数据量超过 1000 条，且没有设置合理的 Batch Size，它会尝试一次性将所有数据加载到内存中。
- Wait 节点：如果设置了 Wait for All Incoming Branches，n8n 会将所有分支的数据缓存在内存中，直到所有分支完成。数据量一大，内存直接爆炸。
- Spreadsheet File：如果你试图一次性读取或写入一个几百兆的 Excel/CSV 文件，内存瞬间撑爆。
笔者建议：在 Wait 节点中，尽量使用 Wait for a Time Interval（定时等待）而不是 Wait for All Incoming Branches，除非数据量极小。
第二步：查看 n8n 日志报错
当崩溃发生时，不要只看界面，要去看后台日志。如果你使用的是 Docker 部署，使用命令 docker logs -f n8n-container。
典型的 OOM 报错代码如下所示：
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
或者在日志中看到 ERR_CONNECTION_RESET 和 502 Bad Gateway。这通常意味着 Node.js 进程已经挂掉，Nginx 等反向代理无法连接到后端。
第三步：监控服务器资源
使用 htop 或 top 命令实时监控。你会发现，当 n8n 运行并行任务时，CPU 可能不高，但 MEM（内存）占用会迅速攀升到 90% 以上，随后服务无响应。
解决方案：从简单到硬核的四步优化法
找到问题后，我们有多种手段来“驯服”内存。请按顺序尝试。
方法一：调整 Node.js 内存堆上限（最简单）
Node.js 默认内存限制较小。如果你的服务器内存充裕（例如 4GB 以上），可以通过环境变量强制提升上限。
如果你是 Docker 部署，需要修改 docker-compose.yml：
environment:
- N8N_BASIC_AUTH_ACTIVE=true
- NODE_OPTIONS=--max-old-space-size=4096 # 将堆内存限制设置为 4GB
如果你是 PM2 或本地启动，可以这样：
export NODE_OPTIONS="--max-old-space-size=4096"
pm2 start n8n
注意：这只是“止痛药”，不是“根治药”。如果代码逻辑有泄露，堆内存调大依然会崩。
方法二：使用 Split in Batches 节点（核心优化）
这是 n8n 并行处理的黄金法则。不要试图一次性处理所有数据，分批处理。
操作步骤：
- 在数据源节点之后，添加一个 Split in Batches 节点。
- 设置 Batch Size（批处理大小）。根据经验，对于 HTTP 请求密集型任务，建议设置为 10 到 50 之间。对于纯 CPU 计算，可以适当调高。
- 将后续的处理节点放在该节点的输出分支上。
这样，n8n 会处理完 50 条数据，释放内存，再处理下 50 条，从而保持内存占用稳定。
方法三：优化 Code 节点的数据处理
在 Code 节点（JavaScript）中，避免使用 while 循环处理大数组，或者使用 push 不断向数组追加数据。这会导致 V8 引擎频繁进行内存分配和垃圾回收。
错误写法：
let result = [];
for (let item of items) {
result.push({ json: { ...item.json, extra: "data" } });
}
return result;
优化写法（利用 map）：
return items.map(item => ({
json: { ...item.json, extra: "data" }
}));
虽然这只是微优化，但在处理 10 万级数据时，差异巨大。
方法四：调整 Wait 节点的并发模式
如果你必须等待多个任务完成，请务必修改 Wait 节点的配置：
- 不要选 Wait for All Incoming Branches（这会把所有分支的数据全缓存在内存里）。
- 改用 Wait for a Time Interval，给下游任务足够的时间去处理，或者使用 Wait for Webhook 回调，而不是干等。
预防措施：构建高可用的 n8n 生产环境
为了避免未来再次踩坑，N8N大学 建议你在生产环境中遵循以下原则：
1. 数据库分离： 如果你使用 SQLite（默认），它在处理大量并发数据时性能极差。请迁移到 PostgreSQL。在 docker-compose 中配置 DB_TYPE=postgresdb，这能显著提升 n8n 的数据吞吐稳定性。
2. 启用执行数据保存策略： 在 n8n 的设置中，配置 Execution Data Save Policy。不要保存所有成功的执行记录，只保留错误的，或者设置保留天数。这能防止数据库膨胀拖慢 n8n。
3. 物理隔离重型任务： 如果任务真的非常重（例如视频转码、大规模数据分析），不要在主 n8n 实例上跑。启动一个专门的 n8n Worker 实例（n8n 企业版功能，或使用社区版的 Queue 模式配合 Redis），将任务队列化。
FAQ 常见问题解答
Q1: n8n 社区版支持分布式集群吗？
A: 原生的 n8n 社区版是单实例运行的。如果你想实现多节点负载均衡，需要使用 Redis 作为消息队列后端，并启动多个 n8n 实例（Web + Worker），但这需要一定的 DevOps 基础。
Q2: 为什么我的 n8n 在 Docker 里跑，宿主机内存充足但容器还是崩溃？
A: Docker 默认没有限制容器的内存上限。如果宿主机内存耗尽，系统会优先杀掉占用内存的容器进程。你需要在 docker run 或 compose 文件中显式添加 --memory="2g" 参数，同时配合上面提到的 NODE_OPTIONS 限制容器内 Node.js 的使用量。
Q3: Loop Over Items 和 Split in Batches 有什么区别？
A: Loop Over Items 适合对每条数据执行简单操作，但它是同步的（虽然可以并发）。Split in Batches 更适合控制整体流程的节奏，防止内存溢出。在处理大批量数据时，优先选择 Split in Batches。
总结与资源
并行任务跑崩是 n8n 进阶路上的必修课。核心思路无非两点：**限制并发数量** 和 **分批处理数据**。
不要迷信“硬件升级”，代码逻辑的优化才是王道。按照文中的方法，先调整 Split in Batches 的大小，再优化 Code 节点，通常能解决 90% 的内存问题。
如果你在实战中遇到了更诡异的内存泄漏问题，欢迎在 N8N大学 的社区中发帖，带上你的日志截图，我们一起排查。
