问题复现：你的 n8n 是不是一跑大数据就“猝死”？

笔者最近在 N8N大学 的交流群里，看到不少同学在处理大批量数据时，n8n 直接甩出一个 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory，然后进程直接挂掉。

这种 OOM（Out of Memory）崩溃通常发生在你试图一次性处理成千上万条数据时。比如，一次性从数据库拉取 5 万条记录，或者在 Code 节点里对一个巨大的数组进行循环操作。这不仅仅是报错，更是你的自动化流程在大负载下“心力衰竭”的信号。

更隐蔽的是 Memory Leak（内存泄漏）。流程跑完后，内存占用没有释放，导致 n8n 越跑越慢，最后不得不重启容器。别急，这不仅是 n8n 的问题，更多是我们设计流程时的策略问题。

原因分析：为什么 n8n 会“消化不良”？

用大白话讲，n8n 是基于 Node.js 运行的。Node.js 的内存堆栈是有上限的（默认约 512MB 或 1.4GB，取决于版本）。当你的 HTTP Request 或者 Postgres 节点一次性把几千个 JSON 对象塞进内存，并且后续节点还在不断复制这些数据时，内存瞬间就爆了。

最常见的“罪魁祸首”有三个：

• 全量加载（Fetch All）： 没做分页，一次性读完所有数据。
• 死循环引用： 在 Code 节点里创建了循环引用对象，导致 GC（垃圾回收）无法回收。
• Map 滥用： 在循环流（Loop）中，如果使用了 .map() 且数据量巨大，它会生成一个新的大数组，内存占用翻倍。

解决方案一：从“大水漫灌”改为“滴灌” (Batch Processing)

这是解决 OOM 最核心的技巧：分批次处理。不要试图一口吃成个胖子。

假设你要处理 10 万条数据，不要一次性查出来。你需要利用 Split Out 节点或者在数据库查询阶段就做好分页。

1. 使用 Split Out 节点： 即使上游数据量很大，这个节点也可以将一组数据拆分成一个个独立的执行流。但要注意，它并不能减少单次查询的内存占用，它主要用于并行处理。
2. 关键策略 - 分页查询： 在 Postgres 或 MySQL 节点中，不要直接写 SELECT * FROM table。利用 OFFSET 和 LIMIT 写一个循环查询。
3. 实操技巧： 使用 Interval 节点或者 Cron 节点触发，每分钟跑一个批次（比如 1000 条），处理完即止。这样内存永远不会高压。

解决方案二：Code 节点的“瘦身”手术

很多 OOM 发生在 Code 节点中。JavaScript 处理大数组非常吃内存。如果你在 Code 节点里写了类似 const newData = items.map(x => { ... return hugeObj; })，那就是在制造内存炸弹。

优化技巧：

• 避免在循环中创建大对象： 如果不需要的数据，尽早删除。使用 delete item.json.property 来清理无用字段。
• 善用 Return immediately： 在 n8n 的 Code 节点中，如果你处理完数据想返回，不要用 return items; 这种大数组。虽然标准写法是这样，但如果你的数据量极大，试试看能否分批次返回，或者在节点外部分批处理。
• 流式处理（Stream）： 对于读取文件等操作，如果 n8n 原生节点不支持流式读取，考虑使用外部脚本（Python/Go）通过 SSH 节点调用，处理完再返回给 n8n。n8n 擅长编排，不擅长纯计算。

解决方案三：修改 Node.js 内存上限 (简单粗暴但有效)

如果你的服务器配置允许（比如你有 8GB+ 内存），且你确实需要一次性处理较多数据，最直接的办法是给 n8n “加内存”。

这通常通过环境变量来实现。

如果你是 Docker 部署，在 docker-compose.yml 中添加：

environment:
  - NODE_OPTIONS=--max-old-space-size=4096

这将把 Node.js 的内存上限从默认的 ~1.4GB 提升到 4GB。如果你是 PM2 启动，则使用 pm2 start n8n --node-args="--max-old-space-size=4096"。

笔者提醒： 这只是止痛药，不是根治药。如果数据量继续增长，你依然会 OOM。建议配合分批处理使用。

预防措施：监控与日志

不要等到崩溃了才知道内存不够用。你需要监控 n8n 的健康状况。

1. 开启详细日志： 设置环境变量 EXECUTIONS_PROCESS_MODE=main（如果是主进程模式）并开启 Debug 日志，观察哪个节点耗时最长。
2. 使用 Wait 节点： 如果流程涉及外部 API 且数据量大，不要让 n8n 一直挂起等待。把状态存入 Redis 或数据库，用 Wait 节点休眠，分段执行。
3. 定期重启： 如果你无法立刻优化所有流程，设置一个定时任务，每隔 24 小时重启一次 n8n 容器，释放累积的内存碎片。

常见问题 (FAQ)

1. 为什么我的 n8n 在 Docker 里跑着跑着就死了？
大概率是 Docker 容器内的 Node.js 内存限制。你需要在 Docker 的环境变量中设置 --max-old-space-size，或者增加 Docker 容器的内存限制（-m "4g"）。

2. 使用 Split Out 节点能解决 OOM 吗？
它可以解决“处理慢”的问题，让任务并行化。但如果上游节点（比如 SQL 查询）已经一次性把几万条数据加载到内存了，Split Out 也无能为力。必须先解决“数据加载”的问题。

3. 有没有免费的监控工具？
有。如果你用 Docker 部署，可以配合 cAdvisor 或者 Portainer 查看容器的实时内存曲线。N8N大学 建议养成看曲线的习惯，才能在溢出前预警。

总结与资源

解决 n8n 的 OOM 问题，核心思路是：分而治之。不要试图让 n8n 单次吞下海量数据，而是让它分多次、小批量地消化。

核心回顾：

1. 使用分页查询，拒绝 SELECT *。
2. 优化 Code 节点，减少内存引用。
3. 适当增加 Node.js 内存上限作为临时方案。

我是 N8N大学 的首席主编，希望这些硬核技巧能帮你稳住你的自动化流程。技术路漫漫，避坑才能走得更远。