Go HTTP 重试为什么请求体变空：GetBody、Request.Clone 与可重放边界

调用支付网关碰到502报错后，不少人直接把同一个 *http.Request 传给 http.Client.Do 做重试，结果下游服务反馈收到的JSON是空的。这个现象很容易被误判成网关偶发丢包，实际最常见的原因是第一次发送请求时已经把 Request.Body 的内容读完，第二次重试时没有可用的全新读取源。

同一个 Request 为什么第二次像没有发 JSON

先用一个可控的测试服务复现问题。服务端只记录请求体长度，客户端对同一个请求连续发起两次调用：

body := bytes.NewBufferString(`{"order_id":"A1024","amount":1999}`)
req, _ := http.NewRequest(http.MethodPost, server.URL+"/pay", body)

for i := 0; i 

第一次发送前，Transport 会从 Body 中读取JSON内容。第二次继续复用这个请求时，原来的读取指针已经走到流的末尾，服务端收到的可能是零字节内容，请求表现出的异常还可能随传输方式不同而变化。不用急着给循环加更多重试次数，先确认每一次重试尝试实际拿到的 Body 内容是什么。

先按三层证据判断：请求、Body 工厂和传输结果

第一层：确认重试代码是不是复用了同一个请求

把请求指针、请求方法、URL、ContentLength 和尝试编号都写到调试日志里。如果两次日志里的请求指针完全相同，而且代码没有替换过新的 Body，问题的原因就已经很清晰了。不要只看 err != nil 做判断，因为服务端返回502时，客户端也可能拿到一个非空响应和一个看起来可重试的状态码。

log.Printf("attempt=%d req=%p len=%d get_body=%t",
    attempt, req, req.ContentLength, req.GetBody != nil)

第二层：确认 GetBody 是否存在

GetBody 是一个可选函数，不是所有 io.Reader 都能自动生成它。用 bytes.NewReader、bytes.NewBuffer 或 strings.NewReader 创建出站请求时，http.NewRequest 通常会同时设置准确的 ContentLength 和可以重新打开的Body工厂；如果传入的是自定义流或者管道，GetBody 往往是空值。

if req.GetBody == nil {
    return fmt.Errorf("request body is not replayable")
}
freshBody, err := req.GetBody()
if err != nil {
    return fmt.Errorf("create retry body: %w", err)
}
defer freshBody.Close()

第三层：把服务端收到的字节数纳入验证

测试服务可以把 io.ReadAll(r.Body) 的长度和哈希值记录下来；客户端则记录状态码和尝试次数。只有第二次请求的Body长度、关键字段都和预期完全一致，才能判定为重试成功，不能只靠返回200状态码就下结论。

Request.Clone 能解决什么，不能解决什么

Request.Clone(ctx) 适合复制Header、URL、方法和上下文相关的请求元数据，但官方文档明确说明它对Body只做浅复制。也就是说，下面的写法仅仅是复制了请求的外壳：

retryReq := req.Clone(ctx)
// retryReq.Body 与 req.Body 仍然指向同一条读取流
resp, err := client.Do(retryReq)

如果第一次发送已经消费完Body内容，就算调用Clone之后仍然拿不到可读的内容。正确的操作顺序是先Clone请求，再通过 GetBody 生成全新的读取器；如果不存在GetBody方法，就必须由业务代码自己保存原始字节、重新打开文件，或者明确禁止这类请求走自动重试逻辑。

用 GetBody 做一个有边界的重试包装器

下面的实现只对明确允许重试的状态码生效，并且每次尝试都会设置独立的Body。示例使用 bytes.Reader，因此 NewRequest 可以自动准备 GetBody：

func doWithRetry(ctx context.Context, client *http.Client, req *http.Request, maxRetry int) (*http.Response, error) {
    if req.GetBody == nil {
        return nil, fmt.Errorf("non-replayable request body")
    }

    for attempt := 0; attempt  0 || current.Body == nil {
            body, err := req.GetBody()
            if err != nil {
                return nil, fmt.Errorf("build body for attempt %d: %w", attempt+1, err)
            }
            current.Body = body
        }

        resp, err := client.Do(current)
        if err == nil && resp.StatusCode != http.StatusBadGateway && resp.StatusCode != http.StatusServiceUnavailable {
            return resp, nil
        }
        if resp != nil {
            resp.Body.Close()
        }
        if err != nil && attempt == maxRetry {
            return nil, err
        }
    }
    return nil, fmt.Errorf("retry budget exhausted")
}

这段代码的核心不是做多次重试，而是保证每次请求都有独立的读取源。生产环境的实现还应该加入退避策略、总耗时上限、幂等键和可观测相关字段；对于扣款、发货、数据写入这类操作，HTTP层的请求可以重放，不等于业务动作就可以无条件重复执行。

哪些 Body 不该直接交给自动重试

还有一个容易漏掉的边界：请求体就算能重新读取，也不代表请求本身一定是安全的。只有服务端接口具备幂等语义，或者请求携带同一个幂等键，才适合把网络失败和服务端临时错误放进同一套重试策略。

反向验证：用 httptest 检查两次请求的 Body

把服务端记录的Body长度和内容哈希作为断言条件，能避免只检查状态码的假通过用例。测试至少覆盖三种结果：首次失败后重试成功、GetBody为空时快速失败、服务端返回不可重试状态时不重复提交请求。

if got[0] != got[1] {
    t.Fatalf("retry body changed: first=%q second=%q", got[0], got[1])
}

如果请求来自真实的网络流，测试不要偷偷把它换成bytes.Reader之后就宣告修复完成；应该保留一个不可重放的测试场景，确保代码会返回清晰的错误，而不是把空Body直接发到线上环境。

相关问题

Request.Clone 会复制请求体吗？

不会。它只对Body做浅复制；需要重试时要调用GetBody拿到新的读取器，或者由业务代码重新创建Body。

为什么 http.NewRequest 有时能自动重试请求体？

当输入是bytes.Buffer、bytes.Reader或strings.Reader时，标准库可以知道内容来源并自动设置GetBody。自定义的io.Reader通常不满足这个条件。

HTTP 500 都应该重试吗？

不应该。先区分网络错误、网关临时错误和业务拒绝，再结合接口幂等性、Retry-After、退避策略和总耗时预算决定要不要执行重试。

把检查项留在代码评审里

• 每次重试是否都创建了新的 Body，而不只是调用 Request.Clone？
• GetBody 为空时，代码是否明确拒绝自动重试？
• 服务端是否能用幂等键识别重复的业务动作？
• 测试是否核对了第二次请求服务端真正收到的字节，而不只是校验状态码？
• 响应体是否在放弃本次尝试前正常关闭，重试总时长是否设置了上限？