LINE Webhook：讓聊天機器人真正開始互動的核心機制

很多人以為 LINE Bot 是一個一直在「盯著」對話的程式，只要有人傳訊息，它就抓到並回覆。

實際上不是這樣的。LINE Bot 能即時回應，靠的是一個叫 Webhook 的機制——它讓 LINE 主動來通知你的程式，而不是你的程式一直去問 LINE「有沒有新訊息？」

---

輪詢 vs Webhook：兩種截然不同的思路

理解 Webhook 最快的方式，是跟另一種做法對比。

輪詢（Polling）：你的程式每隔幾秒就去問一次「有新資料嗎？」，大部分時候答案是「沒有」，但還是得問。耗資源、不即時、浪費。

Webhook：你先告訴 LINE「有事的話通知我，我的地址是這個」，然後你什麼都不做，等 LINE 來找你。有事情發生，LINE 主動把資料推過來，你處理完回應就好。

這是一個方向完全相反的設計。Webhook 的本質是事件驅動——有事才動，沒事就閒著，效率高很多。

---

Webhook 的運作流程

以 LINE Bot 收到使用者訊息為例：

1. 使用者在 LINE 傳了一則訊息給你的 Bot
2. LINE 的伺服器把這個事件打包成 JSON，送到你設定的 Webhook URL
3. 你的後端伺服器收到這個 HTTP POST 請求，解析事件內容
4. 根據訊息內容決定要做什麼（查資料庫、呼叫 API、組回應）
5. 呼叫 LINE Messaging API，把回覆傳給使用者

整個流程，使用者傳訊息到看到回覆，可以在一兩秒內完成。

---

Webhook 能接收的不只是訊息

LINE Webhook 傳過來的是事件（Event），訊息只是其中一種。LINE 的 Messaging API 定義了很多事件類型：

• message：使用者傳了訊息（文字、圖片、貼圖、位置……）
• follow：使用者加了你的官方帳號為好友
• unfollow：使用者封鎖或取消追蹤
• join：Bot 被加入群組
• postback：使用者點了 Flex Message 裡的按鈕（這是很常見的互動入口）
• beacon：使用者進入了設置 Beacon 設備的場域

這代表你的 Bot 不只能回訊息，還能在使用者加好友的瞬間送出歡迎訊息、在使用者點選選單時觸發對應流程、在使用者進場時自動推播通知。

---

安全性：簽名驗證

Webhook URL 是一個公開的 HTTP 端點，理論上任何人都能對它發送請求。LINE 用簽名驗證（Signature Validation）來解決這個問題。

每次 LINE 送事件過來，HTTP Header 裡會帶一個用你的 Channel Secret 計算出來的簽名。你的程式要驗證這個簽名，確認請求確實來自 LINE，不是別人冒充的。

這步驗證如果漏掉，你的 Bot 就可能被惡意觸發。

---

實際應用場景

自動化客服流程：使用者傳來「查詢訂單」，Webhook 觸發，後端查訂單資料庫，回覆訂單狀態——整個流程不需要人工介入。

活動抽獎觸發：使用者點選 Flex Message 上的「我要抽獎」按鈕，postback 事件送到你的 Webhook，後端執行抽獎邏輯，即時回傳結果。

進場偵測通知：搭配 BLE Beacon，使用者進場觸發 beacon 事件，Webhook 接收後推播歡迎訊息或活動說明。

跨系統整合：Webhook 收到事件後，可以打任何 API——CRM 系統、ERP、資料庫、第三方服務。LINE Bot 變成一個前端介面，Webhook 是把它跟後端系統串起來的橋。

---

一個常見的踩坑點

LINE 對 Webhook 的回應時間有要求：你的伺服器必須在一定時間內回傳 200 OK，否則 LINE 會認為發送失敗並重試。

如果你的處理邏輯比較耗時（比如要呼叫 AI API），正確做法是先快速回 200，把實際工作放到背景非同步處理，處理完再主動推播結果給使用者——而不是讓 Webhook 等到所有事情做完才回應。

這個細節沒注意到，會遇到訊息重複回覆或 Webhook 連線超時的問題。