問題描述#

假設我有 5 個活動資料需要處理，流程設計如下：

1
活動資料 (5 筆)
2
    ↓
3
IF 節點分流
4
    ↓
5
分支 A (2 筆) → 處理 → Merge
6
                        ↓
7
分支 B (3 筆) → 處理 → Merge

預期結果：Merge 節點輸出 1 批，包含 5 筆資料

實際結果：Merge 節點輸出 2 批，第一批 2 筆，第二批 3 筆

讓我們用表格對比一下預期與實際的差異：

原因：n8n v1 的深度優先執行順序#

這個問題的根源在於 n8n v1 的執行順序是深度優先（Depth-First），而不是我們直覺認為的廣度優先。

實際執行流程：

1
IF 節點分流 5 個活動（2 個走分支 A，3 個走分支 B）
2
    ↓
3
n8n 先「完整」跑完分支 A（2 個）
4
    ↓ 到達 Merge → 輸出第一批 [2 筆]
5

6
然後才跑分支 B（3 個）
7
    ↓ 到達 Merge → 輸出第二批 [3 筆]

Merge 節點的 Append 模式不會「等待」所有分支的資料到齊，而是有資料進來就立即輸出。因為 n8n 是深度優先執行，所以第一個分支完成時 Merge 就會輸出一次，第二個分支完成時再輸出一次。

重要觀念

n8n v1 是深度優先執行：先完整跑完一個分支到底，再回來跑下一個分支。分支的執行順序由畫布上的位置決定（從上到下、從左到右）。

解決方案#

1
資料來源 (5 筆)
2
    ↓
3
Loop Over Items (batch size: 1)  ← 新增
4
    ↓ (每次只處理 1 筆)
5
IF 判斷分流
6
    ↓
7
各自的處理流程
8
    ↓
9
回到 Loop Over Items
10
    ↓
11
Loop 的 "done" 輸出 → 自動收集所有 5 筆
12
    ↓
13
後續處理（排序等）

1
分支 A → Merge → Aggregate → 單一批次輸出？
2
         ↑
3
分支 B ──┘

問題描述#

我想使用 Merge 節點的 Combine 模式，透過 category_id 欄位來 join 兩個資料來源：

1
活動資料（含 category_id）
2
    ↓
3
類別資料（含 category_id） → Merge (Combine mode, join by category_id)
4
    ↓
5
期望：活動資料 + 對應的類別資訊

但實際執行後，有些活動明明有對應的 category_id，卻沒有成功合併到類別資訊。

根本原因：Merge 放在 Loop 內，但 Input 2 在 Loop 外#

這是最容易被忽略，但影響最嚴重的問題！ 大多數 Join 失敗的情況都源於這個架構錯誤。

1
❌ 錯誤架構
2

3
類別資料 (Loop 外，只執行 1 次) ──┐
4
                                 ↓ Input 2
5
Loop Over Items                  │
6
    ↓ (loop)                     │
7
    處理活動... ─────────────────→ Merge (在 Loop 內)
8
    ↓                            ↑ Input 1
9
    回到 Loop

解決方案：把 Merge 移到 Loop 外#

正確的架構應該是：

1
✅ 正確架構
2

3
類別資料 (只取 1 次) ─────────────┐
4
                                  ↓ Input 2
5
Loop Over Items                   │
6
    ↓ (loop)                      │
7
    處理活動...                    │
8
    ↓                             │
9
    回到 Loop                      │
10
    ↓                             │
11
Loop "done" 輸出 (全部活動) ──────→ Merge (在 Loop 外)
12
    ↓                             ↑ Input 1
13
後續處理...

為什麼這樣可以運作？

這樣的架構確保：

• ✅ 類別資料只取一次，完整保留不會被消耗
• ✅ 活動資料經過 Loop 處理後一次輸出全部
• ✅ Merge 在 Loop 外執行，能夠正確 join 所有資料

重要原則

Loop 內需要重複使用的資料，來源可以放 Loop 外，但 Merge 必須放 Loop 外！

如果把 Merge 放在 Loop 內，Loop 外的資料只會在第一次迭代時有效，後續迭代會失去資料。

補充：其他可能的 Join 失敗原因#

如果你已經確認架構正確（Merge 在 Loop 外），但 Join 還是失敗，可以檢查以下項目：

1
// ✅ 統一轉換為 number
2
{{ Number($json.category_id) }}
3

4
// 或統一轉換為 string
5
{{ String($json.category_id) }}

原則 1：理解 n8n v1 執行順序#

n8n v1 是**深度優先（Depth-First）**執行：先完整跑完一個分支到底，再回來跑下一個分支。

執行順序受什麼影響？

• 畫布上的節點位置（從上到下、從左到右）
• 分支的繪製順序

實務建議：

• 如果需要精確控制執行順序，使用 Loop Over Items 包裝
• 不要假設分支會「同時」執行

原則 2：Loop + Merge 的正確搭配#

正確的架構模式：

1
✅ 正確模式
2

3
Loop 外的資料 ──┐
4
                ↓
5
Loop 處理中...  │
6
                │
7
Loop done ─────→ Merge (Loop 外)
8
                │
9
                └──→ 後續處理

1
❌ 錯誤模式
2

3
Loop 外的資料 ──→ Merge (Loop 內)  ← 只有第一次迭代有資料
4
                 ↑
5
Loop 處理中... ──┘

記憶口訣：

Loop 內需要重複使用的資料，來源可以放 Loop 外，但 Merge 必須放 Loop 外！

原則 3：Join 前檢查資料類型#

在使用 Merge Combine 模式進行 join 時：

必做檢查清單：

• 兩邊要 join 的欄位資料型別是否一致（string vs number）
• 是否需要開啟 Fuzzy Compare
• 是否需要在 Merge 前統一轉換型別

型別統一方法：

1
// ✅ 方法 1：在 Set 節點或 Code 節點中轉換
2
{{ Number($json.category_id) }}
3

4
// ✅ 方法 2：開啟 Merge 的 Fuzzy Compare 選項

技巧 1：檢查 Merge 的兩個 Input#

點開 Merge 節點，分別查看 Input 1 和 Input 2 的資料：

• 確認兩邊的資料筆數
• 確認要 join 的欄位值和型別
• 確認資料是否為空

如何檢查：

1. 點擊 Merge 節點
2. 在右側面板點選 “Input 1” 或 “Input 2”
3. 查看資料內容和結構

技巧 2：觀察節點執行次數#

如果 Merge 節點被執行了多次，代表資料是分批進來的：

• 查看節點左上角的執行次數標記
• 如果看到 “1/2”、“2/2” 這樣的標記，代表 Merge 執行了 2 次
• 這通常代表你遇到了「問題一」的情況

技巧 3：使用 Sticky Note 標註#

在複雜流程中，使用 Sticky Note（便利貼）標註哪些節點在 Loop 內、哪些在 Loop 外：

1
┌─────────────────────┐
2
│   Loop 外的節點     │
3
│   - 類別資料取得    │
4
└─────────────────────┘
5

6
┌─────────────────────┐
7
│   Loop 內的節點     │
8
│   - IF 判斷         │
9
│   - 資料處理        │
10
└─────────────────────┘
11

12
┌─────────────────────┐
13
│   Loop 外的節點     │
14
│   - Merge           │
15
│   - 最終處理        │
16
└─────────────────────┘

這樣可以幫助你和團隊快速理解流程架構，避免踩坑。

希望這篇文章能幫助你避開 n8n Merge + Loop 的常見陷阱！如果你在使用 n8n 時遇到其他問題，歡迎交流討論。

參考資料：

• n8n 官方文件 - Merge 節點

• n8n 官方文件 - 執行順序說明

• n8n 官方文件 - Loop Over Items 節點