LINE webhook 的 standby 模式：為何沒有 replyToken？
如果 LINE webhook 事件帶有 mode: standby，收到事件並不代表你的頻道應該回覆。LINE 的模組頻道文件清楚說明：待機頻道不應發送訊息，其 webhook 事件也不會包含 replyToken。這是 Chat Control 主導權問題，不是 token 過期或 webhook 傳送失敗的證據。先確認事件模式及接入類型，再決定是否回覆。
重點
- webhook 可以成功送達，但接收頻道未必是回覆方。
- 不要因為缺少
replyToken，便自動改發 push 訊息。 - 模組頻道屬於特定企業接入功能，不是每個機械人都能啟用的一般設定。
- 事件接收、回覆歸屬和發送結果應分開管理。
LINE webhook 的 active 與 standby 代表甚麼？
官方模組頻道 Messaging API 指南要求在回覆前檢查 mode。在文件描述的模組連結關係中，只有一個頻道是 active，其餘是 standby。
| 事件模式 | 文件定義 | 應用程式處理 |
|---|---|---|
active | 接收頻道擁有對話主導權，可以發送回覆或 push 訊息 | 繼續檢查事件類型及正常發送條件 |
standby | 接收頻道處於待機，事件沒有 replyToken | 可處理獲授權的內部工作，但不向客戶發送訊息 |
| 缺失或無法識別 | 尚未確認接入的資料契約 | 檢查原始事件與解析器，不預設為 active |
最後一行是建議的防禦策略，不是 LINE 另一種模式。active 也不代表所有事件都有回覆 token，或全部需要回覆；請查閱 Messaging API 參考文件的個別事件定義。
這與多個一般工具共用一個 Messaging API channel 不同。多工具接入檢查表處理共用憑證、webhook 管理權及配額；模組架構還要確認另一件事：目前由哪個頻道主導回覆？
先確認 Module 文件是否適用
LINE 說明，Module 功能只供完成指定申請的企業客戶使用。不要假定一般機械人有資格連結模組或呼叫 Chat Control 操作。
Chat Control 指南亦提醒：目前提供的模組頻道在連結時會自動取得主導權，即 Default Active，通常不需要手動控制。因此，不應只因看到這份文件，就在每個 webhook handler 加入取得或釋放主導權的呼叫。
先核實實際架構：
- 記錄請求對應的 Official Account、接收頻道及供應商整合。
- 向整合負責人確認是否涉及模組頻道。
- 檢查安全保存的原始事件，不只看轉換後的佇列紀錄。
- 比對解析前後
mode的值及replyToken是否存在。 - 主導權不符預期時，請負責的模組供應商調查，不要無據更換 token 或 webhook URL。
日常日誌不應保留頻道憑證或回覆 token。排障紀錄只需註明 token 是否存在，不必記下其值。
先判斷缺失，再調查過期
token 缺失、token 過期和發送回應遺失，需要不同處理方式。
| 觀察結果 | 應調查的項目 | 不應採取的動作 |
|---|---|---|
原始事件是 standby，沒有 token | 對話主導權及預期回覆方 | 自行產生 token，或自動改發 push |
| 原始事件有 token，worker 卻沒有 | 解析、序列化及佇列欄位對應 | 以更改主導權修復資料轉換錯誤 |
| active 事件沒有 token | 個別事件結構及接入情境 | 假定所有 webhook 都可以回覆 |
| 有 token，但回覆失敗 | 實際 API 回應、使用紀錄及處理延遲 | 將所有失敗歸因於 standby |
| 發送請求逾時 | 結果是否仍然未知 | 立即用另一種操作發送相同答案 |
若確實收到過 token，只是使用太遲或重複使用，請參閱 LINE 回覆 token 排障指南。這與「事件本身沒有提供 token」是不同的處理路徑。
將接收事件與回覆權限分開
建議接收端先完成正常的簽署驗證及持久化。LINE 的 webhook 接收指南說明接收與重新傳送機制。不要刻意令有效的 standby 傳送失敗，期望下一次重送會授予主導權。
接收後，先分類，再建立發送工作：
- **Standby：**只保留獲授權內部處理所需的資料，並記錄本次沒有向客戶發送回覆。
- **Active 且事件可回覆：**由一個業務操作評估回覆，並管理去重及發送結果。
- **契約未明：**暫停自動發送並交由負責人調查，不默認為 active。
這些是應用程式內部決策，不是額外的 LINE 欄位或 API 狀態。保留收到事件時的 mode；不能因後續事件是 active，就把舊 standby 事件改為 active，或當作獲得回覆舊訊息的新許可。
對於延後處理的工作，發送前應遵循目前的回覆歸屬策略。如未能確認歸屬，暫緩發送並交由人員核查，而不是換一種訊息操作。單靠事件去重，無法決定多個工具中誰應回覆。
建議驗收包括：standby 訊息不觸發發送、active 且可回覆的事件、解析器遺失 token、重複傳送，以及排隊期間回覆歸屬變得不明。這些是測試建議，不是正式環境測試結果。
UnifyPort 的適用位置與限制
UnifyPort 的非官方接口是獨立的帳戶接入路徑。LINE 授權參考文件描述 QR Code 登入，以及非同步提供的 QR URL 和 PIN。這不是模組連結流程，也不會取得 Official Account 的對話主導權。
在這條獨立路徑中，使用文件定義的標準化 message.received 事件。Webhook 傳送契約說明設定 signing_secret 後的簽署驗證。不要將 LINE 原生的 mode 或 replyToken 假設套入這個結構，也不要把 UnifyPort 發送描述為恢復 Official Account 缺少的 token。
如果發送身分必須是 LINE Official Account，應繼續使用官方 Messaging API，並與模組供應商確認主導權。改用另一個已連結帳戶，不是 standby 的自動補救方案。
常見問題
standby 是否代表 webhook 離線？
不是。事件可能已正常送達。standby 描述接收頻道的對話主導權，而不是伺服器連線狀態。
沒有 replyToken，可以直接改發 push 嗎？
不能把它當成 standby 的自動補救方案。LINE 要求待機接收方不要發送訊息；問題是誰應回覆，不只是使用哪種方法。
active 一定有 replyToken 嗎？
不一定。仍須確認個別事件是否支援回覆。active 本身不會令所有事件都可回覆。
每個 LINE 機械人都需要 Chat Control 呼叫嗎？
不需要。Module 有特定申請要求，現行指南亦說明 Default Active 行為。加入控制操作前，先確認實際架構。
下一步與參考資料
將安全保存的事件與官方模組頻道指南比對，並明確指定負責回覆的組件。如需要獨立帳戶接入，請查看 UnifyPort LINE 授權契約。
官方資料核對日期：2026-10-27。
令訊息接入變成一條穩定嘅產品管線。
先用統一嘅 API 跑通發送，再用標準事件將所有入站訊息接返去業務系統。