我已發布我的自動化。觸發器是一個 webhook 節點，當 CSV（1000 條潛在客戶）被發送到該 webhook 時，自動化就會啟動，但自動化被 n8n 強制終止了。第一次運行了 3 小時（處理了 260 條潛在客戶）後被強制終止，第二次運行了 6 小時（從頭開始並處理了 500 條潛在客戶）後被強制終止：
我現在正在用不同的設置進行第三次嘗試，設置如下：
如果有人知道可能的原因和解決方案，請告訴我
嘿 @AbdullahShah，在等待回覆的同時，以下是一些可能會有幫助的資源：
建議的資源
自動符合您的問題。
文件：
論壇：
@alexm、@Mark_Tic、@Niffzy - 你們之前幫助過類似的問題，可以看一下嗎？
由 n8n 社群機器人自動建議。這是一個試點 - 請在此分享反饋。
有兩件事你可以直接從你自己的截圖中排除或確認。
這不是工作流逾時。 你的設定截圖顯示「Timeout Workflow」已關閉，所以 n8n 不會因為時間限制而結束執行。而且形狀也不符合逾時的特徵——兩次執行分別在 3h15m 和 6h17m 時停止，而不是在同一點停止。
「Save execution progress」已開啟。 這會讓 n8n 在每個節點之後寫入執行狀態。在處理 1000 個潛在客戶的循環中，這會對單個執行記錄產生大量寫入累積，這是導致長時間執行直到進程被終止的常見原因，而不是節點失敗。這種區別符合你的症狀：一個以任何節點都沒有錯誤結束的執行通常意味著進程被終止，而不是拋出異常。關閉該設定是最低成本的測試方法，你唯一放棄的是從中間恢復失敗執行的能力。
值得注意的是，你的吞吐量在兩次執行中都很穩定——3h15m 內 260 個潛在客戶和 6h17m 內 500 個潛在客戶大約都是每個潛在客戶 45 秒。結束前沒有任何性能下降。它停止而不是放緩，這再次表明進程被終止。
一件容易忽視的事，而且已經發生了。 你的第二次執行從頭開始並達到了 500。第一次已經達到了 260。如果這些節點發送電子郵件，前 260 個潛在客戶會收到兩次相同的冷電子郵件。n8n 中沒有任何警示——重試看起來很乾淨，重複發送不會在任何地方顯示為錯誤。在下次嘗試前，值得在發送電子郵件的那一刻將每個潛在客戶寫入工作表或表格，並在發送前檢查該列表，這樣重新啟動就能恢復而不是重複。對於冷外聯，雙重發送通常造成的損失比失敗的執行更大。
披露：我使用 Claude 幫助解決這個問題。兩個設定觀察是直接從你發佈的截圖中讀取的。記憶體解釋是在給定症狀下最可能的原因，而不是根據你的實例驗證的，我在寫作時沒有檢查文檔。如果你的設定排除了這種可能性，我很樂意被糾正。
兩次失敗都發生在我開啟「儲存執行進度」之前，所以那個設定不可能導致第 #1 和 #2 次執行失敗。雖然現在可能會讓情況稍微變差，但它不是造成原本兩次執行失敗的原因
您的工作流幾乎肯定是因為 n8n 試圖在多小時的運行期間同時在 RAM 中保存所有 1000 個潛在客戶在每個節點上的執行數據而遭遇記憶體不足 (OOM) 崩潰。
您的保存執行進度已設定為保存。
-
解決方案： 將其變更為預設 - 不保存。
-
原因： 啟用此選項時，n8n 會在運行期間持續將每個節點的狀態寫入數據庫。對於 3 至 6 小時的執行，這會造成巨大的瓶頸，導致 RAM 和 PostgreSQL/SQLite 數據庫膨脹，直到 Node.js 進程崩潰或容器被主機終止。
在單個工作流中運行 1000 次重量級迭代最終會耗盡 Node.js 堆記憶體，因為垃圾收集器無法在整個父執行完成前清除數據。
-
解決方案： 使用執行工作流節點將潛在客戶傳遞給較小批次的次級工作流。
-
原因： 當子工作流完成時，n8n 會從記憶體中清除其執行數據，保持父工作流的 RAM 佔用量較小。
你說得對，我的帖子在那點上是錯的。你的第一篇帖子說第三次運行是使用新設定的那次，所以保存執行進度在第 #1 和 #2 次運行時並未開啟，無法解釋它們。我把那個螢幕截圖理解成你的當前狀態，而不是你改變後的狀態。忽略那部分。
從你自己的數據來看，以下幾點仍然成立：
工作流逾時仍被排除。逾時工作流已關閉，兩次運行分別在 3 小時 15 分鐘和 6 小時 17 分鐘結束，而不是在同一時間點結束。
吞吐量從開始到結束始終保持穩定。3 小時 15 分鐘內 260 個銷售線索，6 小時 17 分鐘內 500 個，兩次運行都約每個銷售線索 45 秒。它停止了，而不是先減速，這是一個進程被殺死的跡象，而不是節點拋出錯誤或運行衰退。
除了原因之外，還有一點值得檢查：第 #2 次運行從頭開始重新啟動並達到 500，而第 #1 次運行已經達到 260。如果電子郵件是在該循環內發送的，大約前 260 個銷售線索被聯繫了兩次，沒有任何標誌表明這一點，因為第二次運行本身看起來很正常。在發送步驟之前針對已聯繫的欄位進行檢查可以使重新啟動安全地重複。
披露：我使用 Claude 來幫助起草這些內容。逾時點和吞吐量計算是從你的螢幕截圖和你所述的數字中讀取的。我沒有查看 n8n 的文檔或你的實例，上面我搞錯了設定時間表，所以請相應地權衡。
@kjooleng 和 @ClearStack 都準確地指出了 OOM 當機和重複發送電郵的危險。
當你在單一線性執行或迴圈中處理 1000 個項目時，Node.js 會將所有節點輸入/輸出狀態累積在記憶體中。垃圾回收無法清理物件，直到整個父工作流程執行完成，導致主機 OOM 當機。
以下是解決記憶體洩漏和重複電郵風險的 3 步驟生產模式：
### 1. 子工作流程批次處理模式（解決 OOM）
不要在父工作流程中在一個迴圈中執行所有 1000 個潛在客戶：
1. 使用 **Split In Batches 節點**（批次大小：50-100 項）。
2. 使用 **Execute Workflow 節點** 將每個批次傳遞給次級工作流程。
3. **為什麼有效：** 當每個子工作流程執行完成時，n8n 會立即清空其 RAM 佔用空間並觸發 Node.js 垃圾回收器，在 6 小時運行期間保持記憶體使用量平穩。
### 2. 冪等性檢查（防止重複電郵垃圾郵件）
如 @ClearStack 所指出，如果執行 #1 在潛在客戶 260 處失敗，你重新啟動，潛在客戶 1-260 會收到兩次電郵。
* 在子工作流程內，在電郵傳送節點之前，新增一個 **If / Filter 節點**，檢查 `already_contacted === true`（或查詢你的資料庫中的 `email_sent_at IS NOT NULL`）。
* 如果 `true` → 跳過。
* 如果 `false` → 傳送電郵並立即將資料庫狀態更新為 `contacted`。
### 3. 增加 Node.js 堆積限制（如果自行主控 / Docker）
如果你通過 Docker 或 PM2 自行主控 n8n，預設 Node.js 堆積記憶體限制約為 2GB。對於長期執行的批次工作，在環境變數中增加它：
```bash
NODE_OPTIONS=“–max-old-space-size=4096”
```
*（這將最多 4GB RAM 配置給 n8n 進程）。*
結合 **子工作流程 + 批次處理 + 發送前冪等性檢查** 是在不當機 n8n 或騷擾使用者的情況下執行 10000+ 潛在客戶管道的標準方式。
嗨 @AbdullahShah
根據你設定截圖中的升級徽章，你使用的是 Cloud，其限制遠低於預設的 Node 流程：Trial 和 Starter 獲得 320MiB，Pro-1 640MiB，Pro-2 1280MiB，而 n8n 本身在執行開始前會佔用約 180MiB。一個持續開啟六小時、跨越 1000 個潛在客戶的執行將無法適應剩餘的空間。
將整個列表從單一執行中取出。讓 webhook 將 1000 行寫入試算表或表格，並添加 status 欄位，在此結束，然後從排程觸發器驅動發送，該觸發器拉取第一個 25 行 status 為空的記錄，完成工作，並寫回 sent。每次執行只需幾分鐘，執行結束時會釋放記憶體，崩潰只會影響一個批次而非整個執行。
如果你在評估是否應升級至更大的計畫以取得更多空間，以下連結詳細說明了各層級：
好的，我現在把我的工作流程分成子工作流程來看看這是否能解決 OOM 問題。有人可以澄清一件事嗎？我是否也需要發佈子工作流程以及父工作流程？
我的子工作流程：
Sub1 Non-DNC(1).json (526.6 KB)
不用擔心重複接觸同一個潛在客戶，因為我最後會將這個工作流程與 Instantly AI 整合，所以 Instantly AI 會自動防止重複
是的，父工作流程和子工作流程都必須發佈
只是想要結束這個討論。
原始工作流程在 3–6 小時後被強制終止，沒有任何節點錯誤，因為它始終在記憶體中保留整個 1000 條線索的執行（n8n Cloud 上的經典 OOM）。
我現在已將其拆分：父工作流程只執行 webhook → CSV 提取 → Google Sheet → DNC 篩選 → Split In Batches（大小 1）→ Execute Workflow。所有繁重的工作（Perplexity 研究 + 5× GPT-4 評分 + 電子郵件生成 + Instantly 推送）位於兩個已發佈的子工作流程中，每次運行一條線索，並在完成後釋放記憶體。
我目前正在測試 500 條線索。
對於有經驗的人的問題：使用這種架構，我能否安全地通過 webhook 推送單個 5 000–6 000 條線索的 CSV 檔案，還是即使使用子工作流程模式仍應將列表分成較小的檔案（例如一次 1 000 個）？Cloud 上我應該仍然遵守任何實際限制嗎？
提前感謝。
雖然子工作流記憶體效率高，但**父工作流不是。**當您使用「讀取二進制文件」(CSV) 和「從文件中提取」節點時，n8n 會將該 CSV 轉換為父工作流記憶體中的一個龐大 JSON 陣列。
- 一個 6,000 行的 CSV 在磁碟上可能只有 5MB，但一旦在 n8n 中解析為 JSON 物件，根據有多少列和每個儲存格中有多少文本，它可能會輕易膨脹到 200MB–500MB 的 RAM。
- 「批次分割」節點也持有對整個原始陣列的引用，以跟蹤其索引。
- **風險所在：**如果 CSV 很大或數據很「重」(例如，較長的描述)，父工作流本身可能會在到達第一個子工作流之前就觸發 OOM 殺手。
因此答案是否
一個 6,000 條潛在客戶的運行，一次處理一條潛在客戶並進行大量 AI 呼叫 (Perplexity + 5 倍 GPT-4)，將需要很長時間(根據延遲，可能需要 10–20+ 小時)。
- **問題所在：**如果 n8n 雲端實例進行維護，或者如果發生暫時網路故障導致父執行終止，你會丟失你的位置。
- 因為您的迴圈狀態(您在批次中的位置)儲存在該特定執行的 RAM 中，您無法輕易地「從潛在客戶 #3,402 恢復」。您必須從潛在客戶 #1 重新開始，浪費大量 API 配額和時間。
總的來說，每個 CSV/Webhook 觸發 500 或 1,000 條潛在客戶是更安全的選擇。分塊是正確的方法。
只是想把這件事畫上句號。
原始問題是工作流程在 3 到 6 小時後被 n8n 強制停止，但任何節點都沒有顯示錯誤。結果證明這是一個典型的記憶體不足 (OOM) 問題——n8n 在整個運行期間都將已處理的潛在客戶資料保存在記憶體中。
解決方案是將工作流程拆分成子工作流程。迴圈節點之後的所有內容都被移到了子工作流程中。這樣父工作流程只會在記憶體中保留當前的處理資料，繁重的工作（以及已處理的潛在客戶資料）會在每個子工作流程完成後立即釋放。
透過這項變更，自動化現在可以輕鬆處理 1000 到 2000 個潛在客戶的 CSV 檔案，相比之前在達到 OOM 前大約 300 到 400 個潛在客戶的上限，這是一個巨大的跨越。
非常感謝這個社群中幫助診斷並指引我正確方向的每一位。真的很感謝各位的支持……願神保佑你們所有人，謝謝各位！