為什麼錯誤處理這麼重要？
一條工作流在開發環境能順利跑完，不代表上線後也能「長期」穩定執行。
舉例來說：
- 某天 API 回傳的資料多了一個欄位，格式跑掉 → 流程中斷
- 使用者輸入空值 → Loop 卡住
- 外部服務掛掉 → webhook 一直失敗
如果我們沒有預先設計錯誤處理邏輯，就會變成「等問題發生才手動修」，而這通常發生在半夜、假日、或你正在外面吃飯的時候（笑）。
錯誤處理的基本功：Error Workflow
n8n 其實內建了「Error Workflow」功能，這是一個很強大的保護機制。
簡單來說：
- 你可以設定一條專門的錯誤處理工作流
- 只要主流程有任何節點報錯，就會自動觸發這條錯誤處理流程
常見的應用方式：
- 發一封錯誤通知信給自己（或團隊）
- 把錯誤內容記錄到 Google Sheet / Notion / Database
- 自動進行補救措施（例如重試、回滾資料）
設定方式也不複雜：
- 重新新增一條工作流，第一個節點選擇
Error Trigger。 - 在後面串接你希望的通知或紀錄邏輯。
- 回到主工作流設定 → 勾選「Error Workflow」。
節點層級的錯誤處理：Always Output Data
有時候，我們不希望整條流程因為一個節點報錯就全部中斷。
這時候，可以打開節點裡面 Setting的「Always Output Data」 功能。
這樣做的好處是：
- 即便節點報錯，工作流仍會繼續往下跑
- 你可以在後面的節點自己判斷錯誤並決定要怎麼處理
- 或是選擇你在遇到節點錯誤情況（on Error）時，可以選擇停止或是繼續執行工作流。
這在處理 API、外部系統或不穩定的資料時特別有用。
除錯小技巧：Execution Data 與 Debug 模式
當流程報錯時，n8n 會自動把錯誤紀錄下來。
這邊幾個我自己超常用的除錯技巧：
打開錯誤節點 → 查看 Output / Error Message
- 很多時候，錯誤訊息就藏在這裡，像是「找不到 property」或「Invalid JSON」。
使用 Debug Execution:
- 在開發階段多按幾次
Execute Node，看中間節點資料長什麼樣子，能早一步抓錯誤。
在 Code / Text 節點中加 Log:
- 你可以刻意在節點中打印出值，幫助自己快速定位問題發生在哪裡。
進階用法：重試與備援機制
對於商業流程來說，不能只靠「錯了再通知」。
我自己在一些關鍵流程會搭配這幾種方式：
- 在 API 節點中設定「Retry on Fail」
- 延遲幾秒後重試一次（搭配 Wait 節點）
- 使用 IF 判斷錯誤，再導向備援方案
例如我有一條工作流會抓電商訂單資料，如果主 API 掛了，就自動切換到備援 API，不會整條流程停擺。
最後小結：穩定比華麗更重要
很多人剛開始用 n8n 都會很專注在「做出炫酷的流程」，但真正能長期幫你省時間、替你工作的，其實是那些處理錯誤、補強細節的設計。
一條有錯誤處理邏輯的工作流，才是真正能上線的工作流。
小提醒：
- 不要忽略錯誤訊息，它往往是最好的老師
- 多利用 Error Workflow，讓錯誤自動被紀錄
- IF、Wait、Always Output Data 是穩定流程的好朋友
延伸閱讀（我的 n8n 系列文章）