HTTP 客户端升级后，如何检查代理重试是否导致重复提交
HTTP 客户端升级后，如何检查重试是否导致重复提交？本文用请求计数区分自动重试、重定向重放和连接中断，并说明幂等验证要点。
重复提交往往不是业务代码写错，而是客户端在代理 IP 链路上自动重试了非幂等请求。要验证这一点，得让“请求被执行了几次”变成可观测的数字，不靠肉眼核对结果。下面用一个计数接口做靶子，配合注入失败来暴露重试路径。
怎么判断请求被重复处理了？
业务代码调用一次后，客户端可能发送多次网络请求；这不等于业务副作用也执行多次。对照三类记录：客户端发送尝试、服务端接收次数、同一业务键对应的实际副作用次数。再检查幂等键是否一致。只看最终结果不够，因为重复写入可能互相覆盖而不显错。常见重放入口如下：
- 重试机制：状态码重试 ｜ 触发条件：503、502、连接超时 ｜ 注入方式：让服务端对部分请求返回 503
- 重试机制：重定向重放 ｜ 触发条件：307、308 通常要求保留方法与请求体 ｜ 注入方式：测试网关让 A 重定向到 B，仅跳转一次；循环作为单独负例并限制跳数
- 重试机制：连接重置重试 ｜ 触发条件：客户端认为请求未发出 ｜ 注入方式：代理侧主动断开连接
怎么搭建一个可观察请求次数的测试接口？
测试接口按业务键统计接收次数和副作用次数，并返回请求序号。日志只保留脱敏关联键、必要状态和计数，过滤认证头、Cookie、URL 凭据与业务正文。测试请求应经过被测客户端和代理路径，以便对照客户端发送、服务端接收及业务处理记录。
客户端会在什么情况下自动重试？
客户端的重试策略由具体库、版本、状态码和请求配置决定，不能只按 HTTP 方法推断。下表列的是需要核验的风险：
- 方法：GET / HEAD ｜ 方法语义：幂等 ｜ 待核验的风险：通常可安全重试，仍需核对客户端策略与服务端实现
- 方法：PUT / DELETE ｜ 方法语义：幂等 ｜ 待核验的风险：客户端可能重试，需确认服务端确实做过幂等实现
- 方法：POST ｜ 方法语义：非幂等 ｜ 待核验的风险：重试即可能重复创建，需核对客户端策略、幂等键与服务端处理
- 方法：PATCH ｜ 方法语义：非幂等 ｜ 待核验的风险：部分客户端仍会重试，需按具体版本核对
升级后要特别确认：新版本是否把 POST 也纳入了可重试范围。这正是重复提交最常见的来源。
需要继续核对投递、签名与重试行为，可参考SaaS Webhook 地区测试怎么做？到达、签名与重试。
307 和 308 为什么可能重复发送请求？
客户端若自动跟随 307/308，通常会尝试保留方法和请求体重新发送，但请求体是否可重放、原请求是否已被处理、服务端是否有副作用，都取决于客户端实现与应用设计。
测试时检查客户端是否自动跟随、请求体能否重放，以及 A、B 两端分别收到几次请求：
- 是否携带同一个幂等键；
- 是否重复执行了创建逻辑；
- 是否存在重定向循环。
仅在隔离的测试环境中，可将 Location 指向计数接口，观察客户端是否再次发送请求。请求次数增加说明发生了重放；还需检查服务端是否重复执行了业务操作。若方法或请求体发生变化，应记录具体客户端行为，并对照其版本文档。
代理连接中断时，写请求会不会被重新发送？
断开位置决定服务端是否处理过请求。可在受控环境中分别模拟发送前失败、服务端接收后失败和业务提交后丢弃响应，再对照客户端日志、接收次数与副作用记录。连接重置本身无法说明请求是否已执行。
怎么模拟失败并确认修复有效？
在隔离环境中逐项注入故障：发送前断开、业务提交后丢弃响应、返回 503、A 到 B 的一次 307，以及受控超时。重定向循环另作负例并限制跳数。每轮只改一个条件，记录客户端发送、服务端接收和业务副作用次数。修复后重跑相同用例；只有业务记录没有重复副作用且各层计数符合预期，才算通过。
307/308 的 HTTP 语义见 RFC 9110；客户端是否自动跟随及请求体能否重放，应按具体版本验证。
FAQ
Q：幂等键能避免所有重复写入吗？
A：不能，需确认服务端确实支持幂等键，并验证键的作用范围和保留时间。
Q：读请求和写请求可以使用相同重试策略吗？
A：不应默认相同；写请求需评估服务端处理状态未知时的重复执行风险。
Q：客户端没有收到响应，能否判断服务端未处理请求？
A：不能。连接中断时处理状态可能未知，应通过服务端记录或业务状态核对。