當你的 n8n 自動化流程從簡單的幾個節點，逐漸擴展成一個包含數十、甚至上百個節點的龐然大物時，你是否也曾陷入「義大利麵式工作流」的困境？
整個畫布上，節點與連接線縱橫交錯，宛如一盤混亂的義大利麵。你想修改其中一個小小的邏輯，卻要花費數十分鐘才能理清頭緒，深怕動了一個地方，就導致另一個意想不到的角落跟著出錯。更糟的是，你好不容易在 A 流程中寫好了一段完美的錯誤通知邏輯，現在 B 流程也需要，只好再辛苦地複製貼上一次。
如果你對此心有戚戚焉，那麼你需要的正是軟體工程中的一個核心思想：「模組化 (Modularization)」。而在 n8n 中，實現模組化的關鍵，就是學會使用 Sub-Workflow (子流程)。
這篇文章將是你最完整的 n8n 子流程實戰教學。我們將帶你理解為什麼要拆解你的工作流，並手把手教你如何使用 Execute Workflow 等核心節點，建立可重複使用的功能模組，讓你告別混亂，開始打造清晰、高效且極易維護的專業級自動化架構。
為什麼你需要 Sub-Workflow？軟體工程的「模組化」思維
在深入技術操作前，先讓我們理解「模組化」能帶來什麼好處。將一個龐大的系統，拆解成多個功能單一、職責明確的小模組，能帶來四大優勢：
- 可讀性與維護性 (Readability & Maintainability): 主流程會變得極度簡潔。原本 50 個節點的複雜流程，可以被簡化成 5 個高階的功能區塊，例如「接收訂單」->「驗證資料」->「處理付款」->「更新庫存」->「發送通知」。一目了然，修改和除錯都變得異常輕鬆。
- 可重複使用性 (Reusability): 你可以將一個通用的功能（例如「發送 Slack/Email 複合式通知」）打造成一個獨立的子流程。未來任何工作流只要需要這個功能，直接呼叫它即可，完全無需重複開發。
- 團隊協作 (Collaboration): 不同的團隊成員可以分工合作，各自負責開發和維護不同的子流程模組，而不會互相干擾。
- 效能與錯誤隔離 (Performance & Error Isolation): 你可以將特別耗時或容易出錯的邏輯放到子流程中。如果子流程失敗，不會直接讓主流程崩潰（需要搭配錯誤處理），也方便你針對性地進行效能優化。
Sub-Workflow 的核心節點組合
要實現子流程的設計模式，你需要認識一對「呼叫者」與「被呼叫者」的節點組合。
呼叫者：Execute Workflow 節點
這是你的「主流程 (Main Workflow)」中用來呼叫子流程的節點。它的功能很單純：暫停當前流程，將資料傳遞給另一個指定的工作流，並等待它執行完畢後，再拿著子流程回傳的結果繼續往下走。
被呼叫者：子流程的觸發器 (Trigger)
你的「子流程 (Sub-Workflow)」也需要一個觸發器來接收來自於主流程的呼叫。最常用的是 Webhook 節點，因為它可以接收來自 n8n 內部其他流程的 HTTP 請求。
進階新選擇： 新版 n8n 推出了專為子流程設計的 Callable Trigger 和 Call Workflow 節點。它們的運作原理類似，但設定更為簡潔，是未來官方推薦的主流作法。在本教學中，我們將使用最通用、適用於所有 n8n 版本的 Execute Workflow 與 Webhook 組合來做示範。
建立你的第一個 Sub-Workflow：手把手完整教學
讓我們來實際操作一次。目標是建立一個簡單的「加法器」子流程，主流程會傳遞兩個數字給它，子流程負責將它們相加，並把結果回傳給主流程。
步驟一：建立「子流程」 (被呼叫者)
- 新增一個工作流，並將其命名為
Sub - Calculator。 - 設定觸發器：
- 將預設的
Start節點刪除，換成一個Webhook節點。 - 點擊 Webhook 節點，你會看到一個 Test URL。這個 URL 就是子流程的「地址」，主流程會透過它來呼叫。先將這個 URL 複製下來。
- 將預設的
- 撰寫核心邏輯：
- 在 Webhook 節點後，接上一個
Set節點。 - 我們要計算總和，所以新增一個欄位
sum，並在 Value 中使用 Expression：{{ $json.body.num1 + $json.body.num2 }}。 - 解說： 當主流程呼叫這個 Webhook 時，傳遞的參數會被放在
body物件中。
- 在 Webhook 節點後，接上一個
- 回傳結果：
- 在 Set 節點後，接上一個
Respond to Webhook節點。這個節點至關重要，它負責將處理完的結果「回傳」給主流程。 - 在
Respond with選項中選擇Last Node's Data。
- 在 Set 節點後，接上一個
- 儲存並啟用 (Active): 非常重要！子流程必須是啟用狀態才能被呼叫。 請儲存並點擊右上角的開關來啟用它。
步驟二：建立「主流程」 (呼叫者)
- 新增另一個工作流，命名為
Main - Test Calculator。 - 準備要傳遞的資料：
- 使用
Start節點即可。我們直接在下一個節點準備資料。 - 連接一個
Set節點，在裡面建立兩個欄位：num1(值設為 10) 和num2(值設為 25)。
- 使用
- 呼叫子流程：
- 接上
Execute Workflow節點。 - Workflow ID: 在下拉選單中，選擇我們剛剛建立的
Sub - Calculator。 - Source of data: 選擇
From JSON/RAW。 - 在
JSON Parameters欄位中，我們要定義傳遞給子流程的資料。它的格式是{ "key": "value" }。我們輸入：JSON{ "num1": "{{ $json.num1 }}", "num2": "{{ $json.num2 }}" }這會將主流程中num1和num2的值，傳遞給子流程的 Webhook。
- 接上
- 執行與驗收：
- 執行主流程。你會看到
Execute Workflow節點成功執行後，它的 Output 會是子流程Respond to Webhook節點回傳的資料，裡面就包含了我們計算好的結果：{"sum": 35}！
- 執行主流程。你會看到
實戰案例：打造一個可重複使用的「通用通知模組」
現在，讓我們來看一個更實用的例子。在很多流程中，我們都需要在成功或失敗時發送通知。與其在每個流程中都重複設定 Slack 和 Email 節點，不如把它們打包成一個通用的子流程。
子流程：Sub - Universal Notifier
- 觸發器:
Webhook - 邏輯:
- 一個
IF節點，檢查傳入的type參數是success還是error。 true路徑 (success): 連接到一個Slack節點，發送到#general頻道，訊息內容使用傳入的message參數{{ $json.body.message }}。false路徑 (error): 連接到另一個Slack節點，發送到#alerts頻道，並@channel提醒所有人。
- 一個
- 回傳:
Respond to Webhook節點，回傳{ "status": "sent" }。
主流程中的應用： 現在，在任何你需要發送通知的地方，只需要一個 Execute Workflow 節點，呼叫 Sub - Universal Notifier，並在 JSON Parameters 中傳遞：
JSON
{
"type": "success",
"message": "訂單 #{{ $json.orderId }} 已成功同步！"
}
或是，在錯誤處理路徑中：
JSON
{
"type": "error",
"message": "警告：資料庫寫入失敗！錯誤訊息：{{ $json.error.message }}"
}
如此一來，你就擁有了一個集中管理、可隨時擴充（例如未來想增加 LINE Notify）的通知中心。
Sub-Workflow 設計模式與最佳實踐
- 保持子流程功能單一： 一個好的子流程應該只做一件事，並且把它做好。例如「驗證 Email 格式」、「查詢客戶資料」、「上傳檔案到 S3」。
- 明確的輸入與輸出： 仔細設計你的子流程需要哪些輸入參數，以及它應該回傳什麼樣的結果。這就像是定義一個函式的 API。
- 錯誤處理： 在你的主流程中，
Execute Workflow節點也應該啟用Continue on Fail。這樣，即使子流程執行失敗，主流程也能捕獲到錯誤，並進行相應的處理，而不會直接崩潰。 - 避免無限迴圈： 切勿在 A 流程中呼叫 B 流程，又在 B 流程中呼叫 A 流程，這會導致無限遞迴，耗盡你的伺服器資源。
- 考慮效能：
Execute Workflow預設是「同步」執行，主流程會一直等待子流程完成。如果子流程非常耗時，且主流程不需要等待其結果，你可以考慮在Execute Workflow後面不接任何節點，讓它以「非同步」的方式執行，主流程會立即結束。
結語
學會使用 Sub-Workflow，是 n8n 使用者從「工匠」走向「建築師」的蛻變過程。你不再只是專注於打造單一的工具，而是開始思考如何設計一個由多個獨立、堅固、可重複使用的模組所構成的宏偉系統。
將你那些龐大、混亂的「義大利麵式工作流」，根據功能邏輯，勇敢地拆解成一個個職責明確的子流程吧！這個過程在一開始可能會讓你覺得有點麻煩，但長遠來看，它為你帶來的高度可維護性、可讀性與開發效率，絕對會讓你覺得無比值得。
