本文中的 DocOnly、L0–L3 用於說明本指南的測試執行限制與操作風險，不代表介面是否受支援。介面支援狀態應另查官方文件；修改訊息、會話或傳遞設定前，請核對目標和復原方式。
上線前逐項打勾。核對 token 管理、事件傳遞和重試，以及高風險方法的操作限制。
總覽
按關注點分組的上線前清單，配合末尾的冒煙測試一起用。
Token 安全
token 僅存密鑰管理 / 環境變數，絕不進倉庫。
生產與測試 Bot 分離 token。
CI/CD 注入密鑰；不列印到 build log。
制定 token 洩露輪換 SOP。
Webhook 安全
HTTPS 公網 URL。
配置
secret_token並校驗X-MpChat-Bot-Api-Secret-Token標頭。Webhook endpoint 不暴露管理介面。
先在測試環境驗證，再對生產執行
setWebhook。
限流與重試
用戶端限流 ≤ 每 token 每秒 30 次。
遇到
429時請退避。遇到500或請求逾時時，先確認該操作能安全重試，再決定是否重新傳送。遇到400/401/403時先排查錯誤。遇到409時請確認是否已啟用 Webhook。批量操作控制並發。
日誌脫敏
日誌不出現 token、完整
initData或用戶敏感欄位。錯誤上報配置脫敏規則。
存取日誌不記錄含 secret 的完整 webhook URL。
高危 API（DocOnly，需審批 + 回滾方案）
logOut、leaveChat、deleteMessage(s)、banChatMember、setWebhook、deleteWebhook。部署流水線不包含上述方法的自動呼叫。
維運手冊記錄審批人與回滾步驟。
冒煙測試
getMe——token 有效。getWebhookInfo——URL 正確。模擬用戶訊息——Webhook 收到 update。
sendMessage——回覆成功。（如有）
initData驗簽通過。用測試 Bot 模擬 Webhook 投遞失敗，確認重新投遞沿用原
update_id，並核對業務動作只執行一次。若使用回呼按鈕，確認首次回應成功、重複回應回傳 HTTP 400。
在測試私聊中封鎖 Bot，確認傳送、轉傳和複製均回傳 HTTP 403。解除封鎖後，確認新訊息成功送達。
為什麼會重複投遞？待投遞數為 0 代表什麼？
Webhook 重新投遞會沿用原
update_id。驗證請求後，先用 Bot 與update_id組成的唯一鍵持久化更新，再回傳 HTTP 2xx（如 200 或 204）。業務處理也要具備冪等性，避免工作重跑時重複回覆或重複變更狀態。一般更新最多投遞 24 小時。按鈕回呼更新最多投遞 150 秒，
answerCallbackQuery另有 300 秒的回應時限。pending_update_count=0表示目前沒有待投遞的更新。若要確認哪些更新已到達服務，請查看getWebhookInfo的近期投遞錯誤，並核對服務端的接收和處理記錄。