接口冪等怎麼做提示詞（重複提交、支付回調、消息重複消費的冪等方案）
設計下單、支付、退款、發券這類「執行兩次就會出事」的接口時用：讓 AI 按你的場景識別重複請求的來源，選出合適的冪等方案（冪等鍵、唯一約束、狀態機），寫清表結構和代碼，並覆蓋並發與失敗重試的邊界。
通用大模型 對話模型通用
請為下面的接口設計冪等方案。 接口資訊： - 接口作用：[如創建訂單、支付回調、發放優惠券] - 調用方：[調用方]（例：用戶 App、第三方支付平台、消息隊列消費者） - 技術棧：[語言/框架/數據庫/緩存] - 當前實現（如果有）： [粘貼代碼或說明] 請依次完成： 1. 列出這個接口在現實中會被重複調用的所有來源，例如：用戶連點、前端超時自動重試、網關重試、第三方回調重複通知、消息至少投遞一次、運維手動重放。 2. 確定「什麼算同一次請求」：用哪個字段或組合作為冪等鍵（客戶端生成的請求號、業務單號、第三方流水號），說明為什麼。 3. 選擇方案並說明理由： - 數據庫唯一約束（最可靠的兜底）； - 冪等記錄表：鍵、狀態（處理中 / 成功 / 失敗）、響應結果、過期時間； - 狀態機：只允許「待支付 → 已支付」這樣的單向流轉，用帶條件的更新實現； - 緩存預佔（如 SET NX）只作為減少重複處理的手段，不能單獨作為最終保證。 4. 寫清邊界情況的處理： - 第一次請求還在處理中，第二次請求到達，返回什麼； - 第一次處理失敗了，同一個鍵能否重試； - 第二次請求的參數和第一次不同（鍵相同、內容不同），怎麼處理； - 冪等記錄保留多久。 5. 輸出表結構（建表語句）、核心代碼和對調用方的接口約定（請求頭或參數名、重複請求時的返回）。 6. 寫出驗證用的測試場景清單。
高亮處換成你自己的內容：[如創建訂單、支付回調、發放優惠券]、[調用方]、[語言/框架/數據庫/緩存]、[粘貼代碼或說明]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[調用方] 決定了冪等鍵從哪裏來。用戶端接口通常讓前端在進入頁面時生成一個請求號；第三方回調直接用對方的流水號；消息消費用消息 ID 或業務單號。
常見坑：
- 只靠「先查有沒有、沒有再插入」做去重，並發時兩個請求同時查不到，照樣重複。最後一定要有數據庫唯一約束兜底。
- 只用緩存的 SET NX 做冪等，緩存過期或重啟後就失效了，而且業務失敗時容易忘記釋放。
- 同一個冪等鍵帶着不同的參數再來一次，應該明確拒絕（很多支付平台的做法是返回錯誤），而不是悄悄返回第一次的結果。
追問技巧：方案出來後追問「如果在寫入冪等記錄之後、業務完成之前進程崩潰，會發生什麼，怎麼恢復」。
示例輸出
示例，僅供參考（支付回調，節選）
冪等鍵：支付平台的交易流水號 trade_no，同一筆支付無論通知多少次都相同。
sql
CREATE TABLE payment_notify (
trade_no VARCHAR(64) PRIMARY KEY,
order_id BIGINT NOT NULL,
status VARCHAR(16) NOT NULL, -- PROCESSING / DONE
created_at DATETIME NOT NULL
);處理流程：插入記錄（主鍵衝突說明已處理過，直接返回成功）→ 訂單狀態用 UPDATE orders SET status='PAID' WHERE id=? AND status='UNPAID' 流轉 → 受影響行數為 0 時說明已支付，不重複發貨。
| 情況 | 返回 |
|---|---|
| 重複通知且已處理完成 | 返回平台要求的「成功」應答，不再處理 |
| 金額與訂單不一致 | 拒絕並告警，不更新訂單 |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～