接口幂等怎么做提示词（重复提交、支付回调、消息重复消费的幂等方案）
设计下单、支付、退款、发券这类「执行两次就会出事」的接口时用：让 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 条评论
还没有评论，来抢沙发～