調用外部服務的錯誤處理怎麼寫：重試、超時、熔斷與降級審查提示詞
代碼裏要調用第三方接口、下游微服務、數據庫或消息隊列時用：讓 AI 檢查超時有沒有設、哪些錯誤能重試、重試會不會造成重複操作、下游掛了怎麼降級，並給出改好的代碼。
通用大模型 對話模型通用
請以「下游隨時可能變慢、報錯或完全不可用」為前提，審查下面這段調用外部依賴的代碼。 背景： - 語言與使用的客戶端庫：[如 Go + net/http] - 被調用的依賴：[如短訊服務商接口、訂單服務] - 這個調用所在的場景：[如用戶下單的同步請求、後台定時任務] - 調用是否有副作用：[只讀查詢/會扣款或發消息] - 下游的超時或限流說明：[文檔寫的限制，沒有就寫未知] - 代碼： [粘貼代碼] 檢查清單： 1. 超時：連接超時和讀取超時是否都設定了；整體耗時有沒有上限；同步請求場景下，所有重試加起來會不會超過上游給我們的時間。 2. 錯誤分類：哪些錯誤可以重試（網絡抖動、超時、明確的 503 / 429），哪些絕對不能重試（參數錯誤、鑑權失敗、業務拒絕）；代碼是否區分了。 3. 重試策略：次數上限、指數退避加隨機抖動、是否遵守 429 返回的 Retry-After。 4. 冪等：有副作用的調用重試前，是否有冪等鍵或去重手段，避免重複扣款、重複發短訊。 5. 保護措施：下游持續失敗時是否需要熔斷；有沒有降級方案（返回緩存、預設值、排隊稍後處理）以及降級時如何告知用戶。 6. 可觀測性：失敗時日誌是否包含足夠定位的資訊（下游名稱、耗時、狀態碼、請求 ID），且不打印密鑰和個人資料；是否有失敗次數指標。 7. 資源：響應體是否關閉、連接是否複用、並發調用是否有上限。 輸出： - 問題表：問題 | 風險場景 | 建議； - 改寫後的完整代碼，用這個語言常用的方式實現（可以使用成熟的庫，說明庫名）； - 一張「錯誤類型 → 處理方式」的對照表，方便團隊以後複用。
高亮處換成你自己的內容：[如 Go + net/http]、[如短訊服務商接口、訂單服務]、[如用戶下單的同步請求、後台定時任務]、[只讀查詢/會扣款或發消息]、[文檔寫的限制，沒有就寫未知]、[粘貼代碼]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[調用是否有副作用] 決定了重試策略的上限——只讀查詢可以放心重試，扣款、發短訊、創建訂單這類調用沒有冪等保護時，一次重試就可能造成真實損失。[這個調用所在的場景] 用來判斷能等多久，用戶同步請求一般只能等幾秒，後台任務可以慢慢重試。
常見坑：
- 很多 HTTP 客戶端預設沒有超時或超時極長，下游一卡住，線程或連接就被佔滿，最後整個服務不可用。
- 對所有錯誤統一重試，會把「參數錯誤」重試三遍，或者在下游已經過載時繼續加壓。重試要加退避和抖動。
- 多層調用每層都重試 3 次，最底層實際會被調用 27 次。重試最好只放在一層。
追問技巧：追問「模擬下游超時、返回 500、返回 429、連接被拒絕四種情況，分別說明這段代碼會怎樣表現」，再讓它寫成測試用例。
示例輸出
示例，僅供參考（錯誤類型對照表節選）
| 錯誤類型 | 例子 | 處理方式 |
|---|---|---|
| 網絡抖動 / 超時 | 連接重置、讀超時 | 退避重試，最多 2 次；有副作用時必須帶冪等鍵 |
| 限流 | HTTP 429 | 按 Retry-After 等待；超過整體時限則降級 |
| 下游故障 | HTTP 503 | 重試 1 次，連續失敗觸發熔斷 30 秒 |
| 請求本身有誤 | HTTP 400 / 401 / 403 | 不重試，記錄日誌並告警 |
| 業務拒絕 | 餘額不足 | 不重試，原樣返回給上游 |
go
client := &http.Client{Timeout: 3 * time.Second} // 整體超時，含連接與讀取
req.Header.Set("Idempotency-Key", orderID) // 重試時保持同一個鍵同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～