n8n Loop Over Items／Split In Batches 節點：批次處理大量資料不卡頓

n8n 的 Loop Over Items 節點（舊名 Split In Batches）是用來把大量資料切成小批、一批一批處理的核心節點。當你要對上千筆資料各打一次 API，直接全部送出會被對方擋（rate limit）或拖垮流程；用它分批，就能穩穩跑完不卡頓。

很多人第一次處理大量資料就踩雷：抓回 2000 筆名單想逐筆更新到 CRM，結果不是被 API 回 429 Too Many Requests，就是工作流卡很久甚至逾時。問題不在資料多，而在「一次全送」。正確做法是分批——這正是 Loop Over Items 的職責。

本文是 n8n 核心節點完全攻略 的延伸深入。先讀核心節點地圖建立全局框架，再回來深入這顆批次節點更好懂。

先釐清：n8n 的「迴圈」和你想的不一樣

寫過程式的人看到「Loop」會想到 for 迴圈，但 n8n 的資料流模型不同，這裡要先轉個觀念。

n8n 預設就是 逐項處理：一個節點收到 100 個 item，它會自動對每個 item 各跑一次，你不用寫迴圈。所以很多「我要對每筆資料做某事」的需求，根本不需要 Loop 節點——後面接的節點自己就會逐項跑。

那 Loop Over Items 是幹嘛的？它解決的是 「不能一次全送、要分批控制節奏」 的場景，而不是「逐項處理」本身。搞混這點，是新手最大的卡關。

什麼時候才真的需要 Loop Over Items

三種典型場景：

• 避免 API rate limit：要對 500 筆各打一次外部 API，全送會被擋。分成每批 50 筆、批次間隔幾秒，就能避開限制。
• 分段呼叫、控制用量：例如每次只丟 10 筆給 AI 模型處理，控制成本與 token 用量。
• 大批資料要喘口氣：資料量大到一次處理會逾時，切小批讓流程穩定跑完。

如果你的需求只是「每筆資料都做同一件事、沒有節奏問題」，那不用這顆，直接接下一個節點即可。

Batch Size：唯一最重要的設定

Loop Over Items 的核心參數就是 Batch Size（每批幾筆）：

• Batch Size = 1：一次處理一筆，最細、最安全，適合每筆都要單獨呼叫 API 的情況。
• Batch Size = 50：一次處理 50 筆。在「不要太慢」和「不要被擋」之間取平衡。
• 數字怎麼定？看對方 API 的 rate limit。文件若說「每分鐘最多 60 次」，就把批次大小和間隔調到不超過這個速率。

沒有萬用數字，原則是：會被擋就調小、太慢就調大，拿真實資料試跑幾次抓出甜蜜點。

迴圈的接線：done 與 loop 兩條路

Loop Over Items 節點有 兩個 output，這是它和一般節點最不一樣、也最容易接錯的地方：

• loop（迴圈體）：每一批資料從這裡出去，接你要對每批做的處理（呼叫 API、加工資料等）。處理完一定要把線接回 Loop 節點的輸入，形成一個圈，它才會繼續送下一批。
• done（完成）：所有批次都跑完後，資料從這裡出去，接迴圈結束後要做的事（彙總結果、寄通知等）。

接線口訣：loop 出去處理完繞回來，done 接收尾。 忘了把 loop 接回去，迴圈只會跑第一批就停。

好消息：不必自己加 IF 判斷停止

舊教學常教你用 IF 節點判斷「還有沒有資料」來決定要不要繼續迴圈——新版的 Loop Over Items 不用了。它會自動把進來的資料分完批、全部送完就停，並從 done 分支往下走。你不必再手動寫停止條件，這也是它從舊版 Split In Batches 進化的重點之一。

所以現代寫法很乾淨：資料 → Loop Over Items → loop 分支處理 → 繞回 Loop → 自動跑完 → done 分支收尾。完整節點行為見 n8n 官方 Loop Over Items 文件。

搭配 HTTP Request 的批次選項，雙重保險

如果你分批的目的就是「打 API 不被擋」，其實有兩個地方可以節流，可以擇一或併用：

1. HTTP Request 節點內建的 Batching：直接在請求節點設 Items per Batch 和 Batch Interval，簡單情境用這個就夠。
2. Loop Over Items 節點：當迴圈體裡不只一個 API、還要做多步處理時，用它把整段邏輯包成一批一批跑，控制力更強。

兩者的選擇與設定，在 HTTP Request 節點全攻略 裡有更完整的對照，建議一起讀。

常見陷阱整理

分批處理最容易出問題的三個地方：

• 忘了把 loop 分支接回去：只跑第一批就停。檢查迴圈有沒有形成閉環。
• 在迴圈內覆蓋資料：每批的結果要妥善累積，別讓後一批蓋掉前一批。需要彙總時，迴圈外用 Merge 或在 done 分支處理。
• Batch Size 設太大：以為快，結果還是被 API 擋。先小再慢慢加。

迴圈相關的疑難，也可以對照 n8n 常見錯誤 Top 10 一起排查。

小結

Loop Over Items 不是「讓 n8n 會迴圈」的節點——n8n 本來就逐項處理。它真正的價值是 控制處理的節奏：把一大批資料切小、分批、留間隔，避開 API 限制、避免逾時。記住 Batch Size 看對方 rate limit、loop 分支要繞回來、done 分支收尾這三件事，大量資料就能穩穩跑完。

想複習其他核心積木，回 n8n 核心節點完全攻略；搭配 IF／Switch 條件節點 做分流、HTTP Request 節點 接資料，你就有了處理真實大量資料的完整工具組。