Go HTTP 重试为什么会重复提交业务请求

Go 里把 client.Do(req) 放进循环，并不等于“失败了再做一次”这么简单。网络超时只说明客户端没有及时拿到完整结果，服务端可能已经完成了创建、扣款或写入；此时再次发送同一个 POST，就可能把一次业务意图变成两次提交。

安全的做法是：先判断请求是否允许重试，再为每次尝试重新创建请求体；涉及写操作时使用稳定的幂等键，让服务端把重复到达识别为同一个业务请求。不要把所有错误、所有 5xx 和所有 POST 都交给同一段重试循环。

官方资料：https://pkg.go.dev/net/http

为什么一次超时可能已经写入成功

一次 HTTP 调用至少包含“客户端发送请求、服务端处理、服务端返回响应、客户端读取响应”几个阶段。客户端在读取响应前断开、代理超时或连接被重置时，拿到的是一个不确定结果：请求可能根本没有到达，也可能已经被服务端处理完成。

因此，“err != nil”不能直接推出“服务端没有副作用”。尤其是创建订单、提交表单、库存扣减等操作，第二次请求可能再次触发业务写入。http.Client.Do 把网络或协议失败作为错误返回，但非 2xx 状态码本身并不会自动变成 Go error；重试策略必须由业务代码明确决定。

先按请求语义划分重试边界

不要只用 HTTP 方法名做机械判断，但它可以作为第一层筛选：

状态码也只是信号，不是业务保证。例如 503 常表示暂时不可用，但服务端可能已经收到请求；429 需要结合 Retry-After 和接口限流约定。对于写操作，只有在接口明确支持幂等后，才把这些状态纳入自动重试条件。

重试前先解决请求体只能读一次的问题

http.Request.Body 是流。第一次发送后，原来的 reader 可能已经被消费；如果把同一个 req 再次交给 Client.Do，重试可能得到空请求体，或者因为请求已经关闭而失败。官方文档中的 GetBody 就是为客户端需要再次读取请求体的场景准备的，而 NewRequestWithContext 对 bytes.Buffer、bytes.Reader 和 strings.Reader 可以自动填充它。

更直观的方式是保存不可变的原始字节，并在每次循环里新建请求。下面的示例只允许 GET、HEAD，或明确提供幂等键的写请求：

package retry

import (
    "bytes"
    "context"
    "errors"
    "fmt"
    "io"
    "net/http"
    "time"
)

func Do(ctx context.Context, client *http.Client, method, url string, body []byte, idemKey string) (*http.Response, error) {
    // 写请求没有幂等键时直接拒绝重试，避免把网络错误变成重复业务。
    writeMethod := method == http.MethodPost || method == http.MethodPut || method == http.MethodPatch
    if writeMethod && idemKey == "" {
        return nil, errors.New("写请求缺少幂等键")
    }

    for attempt := 0; attempt = 500
        if retryableStatus && attempt 

示例把“是否可重试”和“如何重建请求”放在一起，但没有替业务定义成功标准。调用方拿到最终响应后仍要读取并关闭 resp.Body；如果响应在中途被丢弃，也要先关闭它。

用幂等键把重复到达变成同一个结果

幂等键不是“让网络只发送一次”的开关，它解决的是请求已经重复到达后，服务端如何返回一致业务结果。客户端应在同一业务操作的所有尝试中复用一个稳定键；服务端则需要把键与用户、接口、请求参数摘要和最终结果一起持久化，并用唯一约束防止并发请求同时创建两条业务记录。

func createOrder(w http.ResponseWriter, r *http.Request) {
    // 服务端必须要求幂等键，并把它纳入当前用户和接口的唯一范围。
    key := r.Header.Get("Idempotency-Key")
    if key == "" {
        http.Error(w, "缺少幂等键", http.StatusBadRequest)
        return
    }

    // 生产实现应在数据库唯一约束和事务中完成查询、创建、结果保存。
    saved, err := orderStore.FindOrCreate(r.Context(), r.UserAgent(), key)
    if err != nil {
        // 存储层失败不能伪装成创建成功，否则客户端无法安全恢复。
        http.Error(w, "暂时无法处理", http.StatusServiceUnavailable)
        return
    }
    w.Header().Set("Content-Type", "application/json")
    // 首次请求和后续相同幂等键的请求都返回保存过的业务结果。
    _, _ = w.Write(saved.JSON)
}

真实项目中，FindOrCreate 不能只是进程内的 map。多实例部署、进程重启和并发请求都要求去重记录放在共享存储里；如果同一个键再次出现但请求参数不同，应返回参数冲突，而不是复用错误的旧结果。

只重试真正适合的错误，并正确处理响应体

建议把重试条件写成可审查的策略表，而不是一个宽泛的 if err != nil：

• 上下文已经取消或超时：停止重试，把控制权交给上层。
• 连接建立失败或明确的临时网络错误：仅在请求语义允许时有限重试。
• 429：尊重服务端的退避提示，并控制并发。
• 5xx：只有接口已经具备幂等保障时才考虑重试。
• 业务 4xx：通常是参数、权限或状态问题，重试不会改变结果。

每次拿到响应后都要先决定是否消费它。准备继续下一次时，读取到 EOF 再关闭；准备返回给调用方时，把关闭责任交给调用方。Go 官方文档也强调，响应体没有读完并关闭时，底层连接可能无法被后续请求复用。

一份上线前的重试检查表

1. 这个请求是否有业务副作用？有就先默认不重试。
2. 超时后服务端可能已经成功吗？如果可能，必须设计幂等键或业务唯一号。
3. 每次尝试是否重新创建了请求体？不要复用已消费的 Body。
4. 是否限制次数、总耗时和退避？避免故障时形成重试风暴。
5. 服务端是否用共享存储和唯一约束去重？进程内缓存不能覆盖多实例场景。
6. 重试和最终响应是否都有可关联的日志字段？至少记录幂等键、尝试次数和最终状态。

归根结底，Go HTTP 重试的关键不是把循环写得更复杂，而是把“不确定结果”变成可恢复的业务协议：客户端只在明确边界内重试，服务端用稳定的幂等键返回同一个结果，双方再用超时、退避和响应体管理控制资源。

相关问题

POST 请求收到 503 后能不能重试？

只有当接口明确支持幂等键或等价的业务去重机制时才建议自动重试。503 只描述当前响应，不证明服务端没有处理原请求。

为什么重试时不能直接复用 http.Request？

请求体通常是只能向前读取的流。应保存原始字节或提供可靠的 GetBody，并为每次尝试创建新的请求。

幂等键每次重试都要换吗？

不要换。同一个业务操作必须复用同一个键；换键会让服务端把每次重试误认为新的业务操作。