n8n 串接 LINE 與 Google Sheets：從 webhook 到防重送的實作架構
把 LINE 訊息寫進 Google Sheets 看似只有三個節點，真正上線時卻必須處理簽章、重送、順序、配額與個資。可靠的流程應先把 webhook 收件與後續處理解耦，再以事件識別碼避免同一訊息被寫入兩次。
建議架構
資料流可拆成：LINE webhook 收件 → 驗證簽章 → 快速回應成功 → 檢查事件是否處理過 → 清理與分類欄位 → 寫入 Google Sheets → 記錄結果或通知錯誤。
LINE 官方建議先驗證 webhook 簽章，並非只靠來源 IP 判斷。驗證需要原始 request body；如果中介層先改變空白、編碼或 JSON 格式，可能造成驗證失敗。因此要先保留原始內容，再交給後續節點解析。
為什麼要防重送
LINE webhook 官方文件指出，相同事件可能因網路等原因送達多次，啟用 redelivery 後順序也可能和事件發生順序不同。可使用 webhookEventId 作為冪等鍵：寫入前先查是否存在，存在就停止，不存在才處理並保存。
不要只用使用者 ID 加時間判斷，因為同一人可能在短時間送出多則不同訊息。若流程需要依序處理，還要參考事件 timestamp，並明確定義較晚到達的舊事件該怎麼辦。
Google Sheets 不是無限資料庫
Google Sheets 適合低到中量、需要人工查看的名單，但不適合作為所有情境的交易資料庫。Sheets API 使用限制包含每分鐘配額；超過時可能回傳 429，官方建議使用截斷式指數退避。
實作時應批次寫入、限制重試次數並加入隨機延遲，避免大量失敗任務同時重送。若資料量、併發或一致性要求上升，應改用正式資料庫，Sheets 只保留報表或人工審核用途。
n8n 節點配置重點
- Webhook 節點只負責接收，不在回應前執行耗時 AI 或多次 API 呼叫。
- 驗證失敗立即拒絕，且不要把密鑰或完整 request 寫進通知。
- 以資料庫、資料表或可原子寫入的儲存層記錄事件 ID。
- 對文字長度、允許欄位、個資與公式注入做輸入檢查。
- 寫入 Sheets 前把以
=、+、-或@開頭的非預期內容視為風險資料處理。 - 錯誤路徑保存最少必要資訊，通知負責人，不無限重試。
測試案例
- 同一
webhookEventId連送兩次，只新增一列。 - 事件反序到達時，業務狀態不會被舊訊息覆蓋。
- Sheets 回 429 時會退避，超過上限轉人工處理。
- 欄位缺漏、過長或包含試算表公式時被安全處理。
- LINE 簽章錯誤時不執行後續節點。
- 流程重跑不會重複發送對外訊息。
完成串接後，建議搭配n8n 安全與維運清單做上線審查，再用流程 ROI 指南確認維護成本。如果需要協助設計，可查看n8n 流程自動化服務。