Postman需用Collection Runner模拟高频重复请求以验证后端防重逻辑，设置Iterations和Delay（如50次、100ms），并确保token、request_id等上下文正确传递，否则测试无效。
Postman怎么发多次相同POST请求
直接用Postman重复点击「Send」不算真正意义上的重复提交测试——它不模拟用户在极短时间内连续触发、也不覆盖session/token等上下文状态。真要验证后端防重逻辑，得用Collection Runner或Runner功能批量发请求。
常见错误现象：手动点5次Send，发现后端只拦截了1次，其余4次都成功入库。这不是后端没生效，而是每次请求之间间隔太长（>默认防重窗口，比如2秒），被当成合法新请求处理了。
- 打开已有请求 → 点击右上角「Save」存入某个
Collection - 点击左上角「Runner」→ 选中该
Collection→ 设置「Iterations」为50（模拟高频提交） - 勾选「Delay between requests (ms)」填
100（100ms间隔，更贴近真实误点场景） - 点击「Run」，观察响应里
200和400（或自定义错误码如429）的比例
注意：如果接口依赖session或Cookie，必须在Runner里启用「Persist variables」并勾选「Clear cache and cookies before run」，否则每次请求会复用上一次的会话状态，导致防重失效。
如何让Postman带token或request_id提交表单
很多后端防重逻辑依赖前端传来的request_id或X-Request-ID头，而Postman默认不自动携带。你得手动补全，否则测试结果全是“漏网之鱼”。
使用场景：后端用@RepeatSubmit注解 + RepeatSubmitInterceptor校验，但拦截器只检查request.getParameterMap()和当前时间戳，不校验header——这时你得确保每次请求的request_id参数是唯一的。
- 在请求的
Body → raw → JSON里，显式加上"request_id": "8f7a2b1e-3c4d-5f6a-7b8c-9d0e1f2a3b4c" - 或者在
Headers里加一行：X-Request-ID→{{requestId}}，再在Collection的Variables里定义requestId为{{$$guid}}（Postman内置变量，每次请求生成新UUID） - 若后端校验的是
session中的token，需先用一个GET请求获取token，写进环境变量，再在后续POST的Headers中填Authorization: Bearer {{token}}
容易踩的坑：{{$$guid}}在Collection Runner里每轮迭代都会刷新，但如果你在单个请求里多次点Send，它不会变——得手动清空或换用{{timestamp}}+{{randomInt}}组合。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
为什么Postman测不出重复提交拦截
最常遇到的情况是：代码写了RepeatSubmit注解，也注册了RepeatSubmitInterceptor，但Postman一跑全过。问题往往不在逻辑，而在拦截器没生效的几个隐蔽点。
-
handler instanceof HandlerMethod为false：比如你用的是Spring WebFlux或直接返回ResponseEntity，HandlerMethod拿不到，preHandle直接跳过校验 -
session.getAttribute(SESSION_REPEAT_KEY)始终为null：Postman默认不维护JSESSIONIDCookie，需在Settings → General里打开「Automatically persist cookies」，或手动在Headers里加Cookie: JSESSIONID=xxx - 缓存键用的是
request.getRequestURI()，但前端实际请求路径带查询参数（如/order/submit?source=web），而后端拦截器没把queryString拼进去，导致两次请求被视为不同地址 - 时间窗口设为
5000ms，但Runner里延迟填了10000，所有请求都隔开超时，自然不触发拦截
性能影响提示：RepeatSubmitInterceptor里如果对getParameterMap()做了JSON.marshal，高并发下序列化开销明显；生产环境建议改用Arrays.deepHashCode做轻量哈希比对。
用Postman验证数据库唯一约束是否兜底
哪怕后端防重失效，数据库层的UNIQUE KEY也该拦住脏数据——这是最后一道防线。Postman可以快速验证它是否真起作用。
操作步骤很简单：先用一个正常请求插入一条记录，拿到返回的request_id；再把这个request_id原样复制到第二个请求的body里，发出去。
- 预期响应：HTTP状态码
500或409，响应体含DuplicateKeyException或自定义错误信息如"订单已存在" - 如果返回
200且数据库多出一条记录，说明唯一索引没建对——检查SQL里是不是漏了USING BTREE或字段类型不一致（比如request_id定义为VARCHAR(32)但实际传了36位UUID） - 注意MySQL 8.0+默认开启严格模式，
INSERT IGNORE会静默失败，必须用ON DUPLICATE KEY UPDATE或捕获异常，否则Postman看到的只是“成功”，数据却没写进去
容易被忽略的地方：唯一约束只对**完全相同的值**生效。如果两个请求的request_id看似一样，但一个是带双引号的JSON字符串"abc"，另一个是无引号的abc，数据库会认为它们不同——这要求前后端对参数类型的处理必须严格一致。
