Postman中添加幂等请求头X-Idempotency-Key需手动在Headers填写，推荐用{{$$guid}}保证唯一；若需跨请求复用，须在Tests中提取并set变量，再通过{{idempotency_key}}注入；关键要验证服务端是否真校验、key是否唯一且生命周期匹配业务。
Postman里怎么加幂等请求头（比如 X-Idempotency-Key）
直接在请求的 Headers 选项卡里手动添加就行，不需要插件或脚本。关键不是“能不能加”，而是加对了没、值是否真唯一、是否被服务端校验。
常见错误是填了个固定字符串如 "abc123"，或者用时间戳但没带毫秒——服务端一秒钟收十次请求，全撞成同一个 key，等于没设。
- 推荐用 Postman 内置变量
{{$$guid}}：每次发送自动生成 UUIDv4，天然唯一，适合大多数幂等场景 - 如果接口要求 key 和业务强绑定（比如支付订单），就得从上一个响应里提取字段，再注入到下一个请求的 header 中——这时必须配合
Tests脚本 +pm.variables.set() - 注意大小写：
X-Idempotency-Key是 RFC 公认命名，但有些内部系统用X-Request-ID或Idempotency-Key，得看文档或抓包确认
为什么 POST 请求发两次，服务端没返回 409 Conflict？
大概率是幂等 key 没生效：要么 header 拼错了，要么服务端根本没开启校验，要么你用的 key 在服务端缓存里已过期（比如 Redis TTL 设太短）。
电商和支付类接口常把幂等 key 存 Redis，TTL 通常设 24 小时；但测试时如果反复用同一组参数+同一 key，而服务端只保留最近一次处理结果，第二次请求可能直接返回 200 OK（带原始响应体），而不是 409。这不是 bug，是设计选择。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 先确认响应 header 里有没有
X-Idempotency-Used: true这类标识，有说明服务端识别并复用了缓存结果 - 用
console.log(pm.response.code)在Tests里打日志，别光看 UI 响应码——有时 UI 显示 200，实际 body 里写了"status": "idempotent_skip" - 检查服务端日志关键词：
idempotent、dedupe、skip_duplicate，比看 HTTP 状态码更准
如何用 Postman 自动提取并复用幂等 key？
适用于需要跨请求保持幂等上下文的场景，比如先调 POST /orders 创建订单，再调 POST /orders/{id}/pay 支付，两个请求必须用同一个 key 才算真正幂等。
不能靠人眼复制粘贴，得让 Postman 自己记、自己填。核心就两步：从响应里取值 → 写进下一个请求的 header。
- 在第一个请求的
Tests里写：pm.variables.set("idempotency_key", pm.response.json().idempotency_key || pm.variables.get("idempotency_key") || pm.environment.get("idempotency_key")); - 在第二个请求的
Headers里填：X-Idempotency-Key→{{idempotency_key}} - 如果响应没返回 key，就 fallback 到环境变量或生成新值，避免空 key 导致服务端拒绝
幂等测试最容易忽略的三个细节
很多人跑通一次 200 就以为幂等 ok 了，其实漏掉了真实链路里的脆弱点。
- 弱网重试：用 Postman 的
Runner设置 500ms 网络延迟 + 3 次重试，观察第二次请求是否真走幂等逻辑，而不是因为超时重发导致创建了两条记录 - 并发冲突：用
Runner并发发 10 次相同请求，看返回状态码分布——理想是 1 个201+ 9 个409，如果全是201或混着500，说明锁机制或缓存没生效 - key 生命周期：改一次请求体（比如调高金额），再用原 key 发送，应该被拒绝（因业务参数变了）；但如果服务端只校验 key 不校验 body，就会误放行——这属于实现缺陷，得测出来
