幂等性用例设计是什么
幂等性用例设计针对可重试操作（支付、创建订单、回调处理）：同一幂等键的多次请求只产生一次业务效果，并返回一致响应。幂等是重试安全的前提；只重放请求不校验副作用次数，重复扣款这类最贵的问题可能永远测不出来。
基本信息
| 验证对象 | 支付、下单、库存扣减、消息消费等可重试操作 |
|---|---|
| 核心断言 | 业务只发生一次、响应语义一致、无重复流水与通知 |
| 冲突场景 | 相同键不同请求体：应返回明确错误而非静默覆盖 |
| 窗口验证 | 幂等键有效期边界两侧各测一次 |
| 并发验证 | 同一键并发提交，验证只有一次生效 |
幂等验证思路
幂等验证思路
# 同一 Idempotency-Key 提交 2 次，预期：
# - 业务只发生一次（账、单、库存）
# - 两次响应语义一致（或返回首次结果）
# - 无重复流水与重复通知
# 并发场景：同键并发提交，断言仅一笔生效典型使用场景
- 支付回调：网关重发通知时验证只入账一次。
- 客户端重试：超时后自动重试不应造成双单。
- 消息队列：至少一次投递语义下，消费端幂等兜底。
- 批量导入：同一批次文件重复上传的去重行为。
- 库存扣减：并发请求下防止超卖与少卖。
- 对账闭环：按幂等键统计唯一业务数与流水数对账。
幂等键要覆盖「相同键不同请求体」的冲突场景：应返回明确错误而非静默覆盖。
只重放请求不做并发验证，竞态下的重复生效仍是盲区。
断言落在副作用上：账务、库存、通知的次数与金额，比响应码更能暴露重复执行。