N8N Sub-workflow 設計：把重複邏輯拆成可重用的子流程

n8n sub-workflow 是把重複邏輯抽成獨立工作流、再由主流程透過 Execute Sub-workflow 節點呼叫的設計手法，透過參數傳遞與單一定義，解決同樣邏輯散落在多條流程、改一處要改十處的維護惡夢。

你有三條 n8n 工作流，每條結尾都接了一模一樣的「組訊息 → 發 Slack → 失敗重試」。某天 Slack 頻道要換，你得打開三條流程改三次，還可能漏改一條。這就是該用 sub-workflow 的訊號。把那段邏輯抽成一條子流程，三條主流程都去呼叫它，往後改一處全部生效。這篇講清楚什麼時候該拆、怎麼傳參、以及拆過頭的反效果。

本文是 n8n 工作流模板解析系列的進階文章，建議先理解 n8n 核心節點再往下讀。

什麼時候該拆 sub-workflow {#何時拆}

判斷標準只有一條：同一段邏輯出現在兩條以上的工作流，而且未來可能要一起改。 符合就拆。

常見適合抽成子流程的邏輯：

通知模組 — 組訊息、發 Slack／Email／Line、失敗重試
資料正規化 — 把不同來源的 JSON 統一成內部欄位格式
錯誤處理 — 記 log、發警報、寫入死信佇列（DLQ）
檔案轉換 — 上傳、轉檔、回傳 URL
驗證模組 — 統編、Email、手機格式檢查

這些的共通點：邏輯穩定、會被多處呼叫、改動需求會一次套用到所有呼叫端。把它們集中管理，等於替自己省下未來無數次的複製貼上與漏改風險。

Execute Sub-workflow 節點怎麼用 {#execute節點}

Execute Sub-workflow 節點怎麼用 {execute節點}

n8n 用 Execute Sub-workflow 節點（舊版叫 Execute Workflow）來呼叫另一條工作流。

設定步驟：

先把要重用的邏輯做成一條獨立工作流，開頭放 Execute Sub-workflow Trigger 節點（接收主流程傳來的資料）。
在主流程要呼叫的位置加 Execute Sub-workflow 節點。
Source 選 Database，Workflow 下拉選剛建的子流程。
設定要傳進去的輸入資料。

子流程跑完會把結果回傳給主流程，主流程接著往下走。對主流程來說，整段重複邏輯被收斂成一個節點，畫布乾淨很多。節點參數與觸發設定可對照 n8n 官方 Sub-workflow 文件。

傳參與回傳：讓子流程通用 {#傳參}

子流程要能被多處重用，關鍵是不要寫死任何呼叫端才知道的值，全部用參數傳進來。

主流程傳入

在 Execute Sub-workflow 節點，把要傳的值組成 JSON：

{
  "channel": "{{ $vars.slackAlertChannel }}",
  "message": "訂單 {{ $json.orderId }} 處理完成",
  "level": "info"
}

子流程接收

子流程的 trigger 節點會收到這包資料，後續節點用 $json 取用：

// 子流程內的 Slack 節點
Channel: {{ $json.channel }}
Text: {{ $json.message }}

這樣同一條通知子流程，訂單流程傳訂單訊息、報表流程傳報表訊息，子流程本身一字不改。參數從哪來、怎麼用環境變數管，見 n8n 變數與環境設定；表達式取值語法見 n8n 表達式速查表。

回傳結果

子流程最後一個節點的輸出，就是回傳給主流程的內容。想回傳處理狀態，在子流程結尾用 Set 節點組好回傳格式：

{
  "sent": true,
  "channel": "{{ $json.channel }}",
  "timestamp": "{{ $now }}"
}

主流程接到後就能判斷子流程是否成功，再決定下一步。Set 節點用法見 n8n Set 與 Merge 資料節點。

實戰：抽出一條通知子流程 {#實戰}

實戰：抽出一條通知子流程 {實戰}

把開頭那個「三條流程都有通知邏輯」的情境實際拆一次。

Before： 三條工作流結尾各自有一串「Set 組訊息 → Slack 節點 → IF 判斷失敗 → 重試」共四個節點，總共十二個節點散在三處。

After：

新建工作流 notify-slack，放 Execute Sub-workflow Trigger，接 channel、message、level 三個參數。
裡面放組訊息、Slack 發送、失敗重試邏輯（重試機制見 n8n 錯誤處理與重試機制）。
三條主流程各自把原本四節點，換成一個 Execute Sub-workflow 節點，傳入各自的訊息。

結果：通知邏輯從十二個節點收斂成一條子流程（四節點）加三個呼叫節點。Slack 換頻道時，只改 notify-slack 一處。這正是模組化設計的核心價值，相關拆分模式也可參考 n8n Sub-workflow 模組化設計。

不要拆過頭 {#過頭}

模組化很爽，但拆過頭一樣是災難。

只用一次的邏輯不要拆。 子流程的價值來自重用，只被呼叫一次的子流程只是多一層跳轉，反而難追蹤。

別把子流程疊太多層。 主流程呼叫 A、A 呼叫 B、B 呼叫 C，三層以上時，出錯要逐層往下找，除錯成本暴增。控制在兩層內，超過就該重新想拆分邏輯。除錯技巧見 n8n 工作流除錯完整指南。

子流程要有清楚的單一職責。 一條子流程只做一件事（只發通知、只轉檔），不要塞成「處理訂單又發通知又寫 log」的萬能流程，否則重用性歸零。這個「單一職責、介面要窄」的原則，和軟體工程談的關注點分離是同一回事。

判斷拆得對不對，回到那條標準：這段邏輯真的會被多處用、且會一起改嗎？ 是就拆，不是就留在原地。

常見問題 FAQ {#faq}

n8n sub-workflow 和直接複製節點差在哪？

複製節點是每條流程各有一份邏輯，改動要逐條改、容易漏；sub-workflow 是邏輯只有一份定義，多條主流程共用，改一處全部生效。重用次數越多，sub-workflow 的維護優勢越明顯。

子流程可以巢狀呼叫嗎？

可以，但建議控制在兩層內。層數太深時，出錯要逐層往下追，除錯成本會明顯上升。

主流程怎麼把資料傳給子流程？

在 Execute Sub-workflow 節點把要傳的值組成 JSON 輸入，子流程的 trigger 節點會收到，後續節點用 $json 取用。子流程結尾節點的輸出則會回傳給主流程。

子流程出錯，主流程會怎樣？

預設子流程出錯會讓主流程也跟著失敗。想讓主流程自行決定如何處理，可在子流程內做好錯誤處理並回傳狀態欄位，由主流程判斷後續動作。

把重複邏輯抽成 sub-workflow，是 n8n 從「能跑」走向「好維護」的關鍵一步。先找出真正被多處重用、且會一起改的邏輯，用參數讓它通用，再控制好巢狀層數，你的工作流會越長越乾淨而不是越長越亂。

想看更多 n8n 模組化與工作流設計實戰，追蹤 N8NMarket 每週 n8n 精選。

目錄