大家好，
我使用的是 n8n Cloud Starter，版本 2.17.5。
一個通過「Loop Over Items」和「HTTP Requests」處理約 120–400 個項目的工作流程出現「連線遺失／離線」的情況，導致執行中斷。
執行資料不可靠或未正確保存。
即使在減少負載並使用「Data Tables」後，仍然會發生這個問題。
您能否確認這是否為 Cloud 資源／超時問題，以及我的方案是否能支援此工作負載？
Hi @kourG，歡迎！
我會說如果你的工作流程沒有優化，這個數字可能會對你的雲端入門方案造成限制，不過 120-400 對於入門方案的運算存取來說仍然很多：
以下是一些你可以考慮用來優化該流程的指導：
升級你的方案也可以解決這個問題，不過這取決於你的使用案例；如果它成長，你可能需要升級到更高的方案。
在 Cloud Starter 上，透過「Loop Over Items」迴圈處理 120 到 400 個項目並執行 HTTP 請求時，出現「connection lost」通常是執行超過方案的記憶體或時間限制，而非網際網路問題，特別是當每個項目都攜帶大量酬載時更是如此，因為 n8n 在執行期間會將執行資料保存在記憶體中。
有幾個方法可以幫助改善。在迴圈前減少每個項目攜帶的資料，移除不需要的欄位以保持記憶體內的酬載精簡，因為迴圈會保存全部資料。分批較小單位進行處理，並在執行時寫出結果（到資料表或外部儲存），而不是在單次執行中累積所有資料，這樣一旦中途失敗也不會遺失整個執行。也可以考慮分工：一個工作流程用來排隊項目，第二個按批次觸發，這樣就不需要單次執行去保存 400 個項目的狀態。
「執行資料不可靠或未儲存」才是真正的風險，因為在迴圈中途中斷的執行往往已經完成了一半的 HTTP 寫入操作，而你無法區分哪些是來自中斷執行的。讓寫入操作具有冪等性，並在外部表格中追蹤哪些項目已完成，這樣重新執行時可以跳過已完成的項目，而不是重複處理。它是在某個固定的項目計數處失敗，還是隨機失敗？固定計數指向記憶體上限。
歡迎來到 n8n 社區 @kourG
請問能否更新到穩定版本 2.23.4 並回報行為是否仍然存在？
感謝您的回覆。
我已經嘗試過減少資料量大小並將中間資料儲存在資料表中。但是，當「連線中斷/離線」問題發生時，資料表中似乎沒有保留任何資料，就像執行從未完成或中間結果從未被保存一樣。
因此，我正在嘗試了解問題是否與 Cloud Starter 資源限制或執行逾時有關。
關於使用批次的建議，如果我理解正確的話，您建議我將 120–400 個項目分成較小的群組，並逐步處理它們，而不是在單一大型執行中進行。我也在考慮在目前批次在迴圈中完成處理後是否可能載入新批次，以便工作流程可以以較小的塊繼續進行。我將試驗這種方法，看看是否能改善穩定性。
另外，我使用的是 n8n Cloud Starter，無法直接控制升級 n8n 版本，因為版本由 n8n Cloud 管理。請問您能否確認版本 2.23.4 在 Cloud 上是否已可使用，或是否需要 n8n 團隊採取任何行動？
是的，但讓每個批次成為其自己的執行。在同一次執行中載入下一個批次的「迴圈遍歷項目」仍然共享一個逾時/記憶體信封，所以當該次執行被中斷時，檢查點可能會隨之消失。
使用一次執行來取得一個小批次，在移至下一個項目之前寫入每個項目的結果/狀態，然後讓「排程」或「執行工作流程」從仍標記為待處理的列開始下一個批次。對於「資料表」症狀，請發布寫入節點的位置：在 HTTP 請求之前、每個項目之後，還是僅在整個迴圈完成後？