自動化太快有時也是種災難。當你每秒對別人的伺服器發送 100 次請求時，你迎來的不是高效率，而是被當作駭客封鎖 API 權限。
在自動化流程中，我們不僅要學會「怎麼做」，更要學會「何時停」。Wait 節點是控制節奏的煞車踏板，而 No Operation 節點則是幫你整理混亂線路的路標。
學習目標 (Goal)
- 掌握 Wait (等待)：學會設置固定延遲，避免觸發 API 的 Rate Limit (速率限制)。
- 掌握 NoOp (無操作)：學會使用空節點來整理複雜的連線，或是作為測試時的斷點。
核心觀念 (Concepts)
為什麼需要 Wait？
想像你用 n8n 自動抓取 500 筆客戶清單，並立刻將這 500 筆資料透過迴圈發送到 CRM 系統。多數的 SaaS 雲端服務都有 Rate Limit (速率限制)，例如「每分鐘最多 60 次 API 請求」。如果你一次把 500 筆資料砸過去，系統會直接拒絕你的連線，導致工作流崩潰 (HTTP 429 Too Many Requests 錯誤)。
這時，在迴圈中加入一個「等待 1 秒」的 Wait 節點，就能讓這個狂奔的引擎冷卻下來，穩定地走完所有流程。
Wait 的常見模式
- Time Interval (時間區間)：最常見的用法。指定等待
X秒、分鐘或小時。例如發送「註冊歡迎信」後，等待 3 天再發送「操作教學信」。 - Specific Time (指定時間)：讓流程沉睡，直到某個精確的時刻再醒來繼續執行。例如：收集一整天的訂單，到隔天早上 09:00 才統一寄送報表。
No Operation (NoOp) 節點的妙用
這是一個「什麼都不做」的節點。資料進去是什麼樣子，出來就是什麼樣子。 - 作為路標：在複雜的分流 (Switch) 中，有時候兩條路線最後要接到同一個終點。你可以先接在一個 NoOp 節點上，再拉到終點，這樣畫面上看起來會乾淨很多。 - 便條紙作用：你可以在 NoOp 的名稱上打字（例如「👇 以下開始處理 VIP 邏輯」），單純作為註解區塊使用。
節點配置 (Node Setup)
Wait Node
Resume: 設定喚醒的條件。選擇
After Time Interval可設定等待長度。Wait Amount / Wait Unit: 設定具體的數字與單位（如 1 Seconds）。
NOTE
[擷圖情境：展示 Wait 節點設定為等待 1.5 秒的設定畫面]
CAUTION
當流程進入 Wait 節點時，n8n 會將這個執行實例 (Execution) 存入資料庫並暫停。如果你在本地開發測試時設定了一個「等待 5 天」的節點，記得測試完要把正在等待中的紀錄去 Executions 列表手動終止，否則它五天後還會跑出來作亂。
專業操作 (Action)
Step 1: 建立一個太快的迴圈 (Mock)
我們不一定要真的寫迴圈，只要準備一堆資料同時進入某個節點即可。通常，當 5 筆資料同時進入下一個節點時，n8n 會幾乎在同一毫秒處理它們。
- 新增一個
Edit Fields (Set)節點，放入多筆資料（Mock Data）。 - 在後方接上一個
HTTP Request節點（可以隨便 call 一個公開的測試 API，例如https://httpbin.org/get）。 - 如果沒有 Wait，這 5 筆資料會瞬間撞上該 API。
Step 2: 加入煞車踏板
為了保護接收端的伺服器，我們要在中間踩點煞車。
- 在
Edit Fields與HTTP Request之間，插入一個Wait節點。 - 設定
Resume為After Time Interval。 - 數值設定為
1，單位設定為Seconds。 - 再次點擊 Execute Workflow。你會發現右上角的執行狀態會開始轉圈圈，因為每處理一筆資料，流程就會乖乖停頓一秒鐘。
實戰挑戰 (Challenge)
- Webhook 喚醒：
Wait節點除了等時間，還可以設定On Webhook Call。試著設定一個流程：先發送一封帶有核准連結的 Email 給主管，流程進入 Wait。直到主管點擊連結 (呼叫 Webhook)，流程才醒來繼續執行後續的「發佈文章」動作。這就是傳說中的「人工審核 (Human in the loop)」經典架構！
範例 (Example)
這個範例展示了如何利用 Wait 讓連續的資料處理放慢腳步，以及串插 NoOp 節點作為註解標籤。