n8n 用了一段時間之後，踩過的幾個坑
之前寫過一篇為什麼選 n8n，剛上手的時候真的覺得相見恨晚。但用了一陣子之後，老實說，好幾次是在罵髒話的狀態下把問題查出來的。今天就來寫寫這些狀況，給也在用 n8n、或正在考慮要不要用的人參考一下，免得踩坑踩得比我還慘。
- 外部資料的欄位一定要檢查
有次上游服務把 order_id 改成 orderId，連個通知都沒有。更機車的是，n8n 遇到這種狀況不會噴錯，它就是把那個欄位當空值，默默繼續往下跑。結果報表裡的訂單編號那一欄空了好幾天，我完全沒發現，直到有人問我「這個訂單編號怎麼都是空的」，我才後知後覺去查。
後來學乖了，只要是吃外部服務資料的節點，前面一定加個檢查，欄位不對就直接讓它爆掉通知我，不要讓它安靜地繼續跑。
- 權限隨時會出問題
還有一個接 Google Sheets 的節點壞掉，錯誤訊息寫得很含糊，看起來像是權限被改了。我傻傻花了半小時去檢查共用設定，改來改去都沒用，滿頭問號。最後點進節點的執行紀錄才發現，原來 OAuth 憑證過期了，要重新授權而已。
早知道先看這個就好，浪費半小時在錯的方向。現在養成反射動作，只要錯誤字眼帶到「權限」兩個字，第一件事先去憑證列表看狀態，不要急著改流程邏輯。
- Webhook 被重送導致一筆訂單重複處理
這個是我目前印象最深的一次。用 Webhook 當觸發源，我完全沒想過對方系統可能同一個請求重送。某次因為網路不穩重送了三次同一筆訂單，結果 n8n 上沒有做任何重複判斷，就是同一筆資料被處理了三次，然後發了三封一模一樣的通知信出去。收件人回信問我是不是系統壞掉了，真的有夠尷尬。
後來補了一個判斷：先用訂單 ID 查一下是不是處理過，處理過就直接結束，不要往下跑。講白了這就是後端常講的「冪等性」，換到自動化流程裡卻特別容易忘記，因為畫面上就是一條線接一條線，你很難直覺聯想到這條線可能會被執行不只一次。
- 資料型別偷偷變了，結果 1+1=11
節點跟節點之間傳資料，畫面上看起來都差不多，但有些節點會不動聲色把數字轉成字串，或反過來。我曾經因為一個欄位在中間被默默轉成字串，後面做加總的節點沒有報錯，只是把數字全部串接在一起，結果變成了另一串數字，查了老半天才發現根本是型別的問題。
現在只要牽涉到數字運算的欄位，一定要在前後各加一個小節點印出型別，確認過一次才敢放心。雖然麻煩，但總比再被陰一次好。
- 手滑改了正式環境，隔天才發現整批資料算錯
早期比較隨性，想到什麼調整就直接在正式跑的流程上改，改完存檔立刻套用。有次改設定手滑點錯參數，流程當下完全沒有報錯，但那天所有經過那個節點的資料全部算錯，一路錯到隔天才被發現。
現在改用比較保守的做法，先複製一份當草稿，測試過確認資料是對的，才切回正式版本，切換前一定留一份舊版本備份，萬一新版本有問題馬上退回去。這根本是任何系統改版都該有的基本習慣，只是自動化工具因為改起來太輕鬆、太直覺，反而讓人容易忘記。
整體來說 n8n 還是省了我很多重複性的苦工，這點沒有問題。但它讓出錯的方式變得比較安靜，不會跳出一堆 error 讓你一眼看到問題在哪，而是資料默默地跑歪，真的要多一份戒心，不然真的會等到出包被別人發現才知道。
留言區