Telegram 行內按鈕一直載入？檢查 answerCallbackQuery

Telegram 行內回呼按鈕一直載入時，先確認機器人是否為收到的 callback_query 呼叫了 answerCallbackQuery。Webhook 回傳 HTTP 200 不等於完成這次呼叫。Telegram 要求回應回呼查詢，即使不需要顯示通知文字也一樣。應儘快回應互動，另外追蹤耗時業務的執行結果。

重點摘要

• 回呼按鈕產生的是 callback_query，不是一般文字訊息；只處理訊息的程式可能忽略它。
• 將查詢的 id 傳入 callback_query_id，不要改用訊息、聊天室或更新識別碼。
• 通知文字並非必填，不顯示文字也可以回應。
• 載入提示消失，不代表付款、審核或客服操作已完成。

為何載入中的按鈕需要 answerCallbackQuery

Telegram Bot API 官方文件區分回呼按鈕與 URL 按鈕：callback_data 會透過回呼查詢傳給機器人，URL 按鈕則開啟指定連結。請先確認建立的是哪一種按鈕。

回呼互動包含三種不同結果：

結果	確認依據	無法證明的事
Webhook 傳遞已確認	接收端回傳成功 HTTP 狀態	回呼查詢已獲回應
按鈕互動已回應	對該查詢呼叫 answerCallbackQuery	業務操作已成功
業務操作已完成	應用程式提交的實際結果	光是收到或回應點擊並不足夠

官方文件說明，answerCallbackQuery 可顯示通知或警示視窗，成功時回傳 True。必要參數為 callback_query_id，text 則是選填。一般 Webhook 確認不能取代它。

若你的疑問是將 Bot API 方法放進 Webhook 回應本文，還是另外發出請求，請參考 Webhook 回應本文與獨立 API 請求的差別。那是呼叫方式的選擇；本文處理的是按鈕互動沒有獲得回應的問題。

找出故障所在的環節

處理器完全沒有收到回呼

檢查收到的更新類型，不要只搜尋一般訊息紀錄。確認分派邏輯支援 callback_query，並檢查明確設定的 allowed_updates 是否包含它。Telegram 說明，省略 allowed_updates 會沿用先前設定，因此後續設定請求未傳入這個參數，不代表已重設篩選條件。

如果整個更新都未送達，請依 getWebhookInfo 傳遞診斷指南排查。傳遞失敗與應用程式忽略回呼，是兩種不同的問題。

回呼已收到，按鈕仍持續載入

以實際收到的更新核對欄位：

輸入欄位	用途
callback_query.id	傳入 answerCallbackQuery 的 callback_query_id
callback_query.data	存在時當作應用程式輸入解析
callback_query.message	存在時提供訊息脈絡，不可假定每次都有
callback_query.inline_message_id	存在時識別透過行內模式傳送的訊息

Telegram 對一般機器人訊息與行內模式訊息提供不同脈絡。若程式一律直接存取 callback_query.message.chat，可能還沒回應查詢就發生錯誤。

需要查看結果時，獨立發出 answerCallbackQuery 請求。記錄真實的成功或錯誤，但不要暴露機器人 token。不要等待 AI、CRM 或其他耗時服務完成，才提供互動回饋。

載入結束，但業務操作不正確

回呼資料是輸入，不是授權憑證。Telegram 提醒，產生查詢的訊息可能已不包含帶有該資料的按鈕。建議檢查允許的動作、使用者權限及伺服器上的最新物件狀態。

以一個假設的審核流程為例：回應點擊不應直接將申請標示為通過。驗證請求後，只執行一次合法狀態轉換，再另外呈現實際結果。重複傳遞需要去重；重複點擊則需要業務層級的防重複執行機制，兩者並不相同。

驗收互動流程，而不只是 Webhook

發布前請涵蓋以下情境：

• 合法回呼即使沒有通知文字，仍能獲得回應。
• 耗時工作不會阻塞互動回應。
• 缺少 message 不會讓回呼處理器出錯。
• 未知或過期的回呼資料不會觸發未授權動作。
• 重複傳遞或重複點擊不會重做不可撤銷的操作。

以上是建議的驗收項目，不是已執行的測試結果，也不是 Telegram 的回應時間保證。

UnifyPort 的適用範圍

機器人行內鍵盤與回呼回應應保留在 Telegram 官方 Bot API。UnifyPort 的非官方介面用於已連接的訊息帳號，採用另一套標準化事件契約。公開的 Webhook 事件目錄包含 message.received，但未記載 callback_query 事件或 answerCallbackQuery 操作。不要將訊息事件改名當作回呼，也不要假定統一 Webhook 能替機器人回應按鈕。

若還需要帳號層級的訊息接收，應將其接收端與機器人互動處理器分開。UnifyPort 的傳遞文件說明回應本文會被捨棄；在其中回傳 Bot API 方法 JSON，不會執行回呼回應。

常見問題

HTTP 200 能停止 Telegram 按鈕的載入提示嗎？

單獨回傳狀態碼不行。回呼需要 answerCallbackQuery，HTTP 確認只處理更新傳遞。

answerCallbackQuery 一定要附上文字嗎？

不必。text 是選填參數，可以不顯示通知文字。

callback_query_id 要填訊息 ID 嗎？

不是，應填入收到的 CallbackQuery 物件的 id。

統一訊息 Webhook 可以取代回呼處理器嗎？

UnifyPort 目前公開的契約沒有這項能力。回呼處理應留在官方 Telegram 機器人整合中。

下一步與來源

執行一次受控的按鈕點擊，追蹤 callback_query 接收紀錄與實際 answerCallbackQuery 結果。若也需要帳號層級的訊息接收，請先閱讀標準 Webhook 事件契約，再決定共用哪些應用邏輯。

官方來源核對日期：2026-09-22。Telegram Bot API：CallbackQuery、answerCallbackQuery、InlineKeyboardButton 與 allowed_updates。