Go HTTP 客户端请求体重试后读取位置错误怎么办

Go HTTP 客户端第一次发送正常，到了重试、307/308 重定向或故障转移请求时，请求体却变空，最常见的原因是复用了已经读到末尾的 Body。io.Reader 保存的是当前位置，不是可以自动倒带的文件；重试时要么让标准库通过 GetBody 重新拿到一个 reader，要么由业务代码从原始字节重新创建请求。

先看 req.GetBody 是否可用，再看重试代码是否复用了旧的 req.Body。只把 reader 的当前位置改回开头，不能替代为每次尝试创建独立 reader。

先判断：是请求体被消费，还是重试根本没发生

把现象分成三类，定位会快很多：

• 首次请求能到达服务端，服务端收到完整数据；第二次请求的长度为零或 JSON 解码报 EOF，优先怀疑旧 Body 已经被读完。
• 收到 307 或 308 后，请求方法保留但新请求没有体，检查 GetBody。Go 文档明确说明，这类重定向要保留请求体，必须有可调用的 Request.GetBody。
• 网络错误后没有自动重试，不能简单归因于 reader 位置。Transport 只会在满足幂等条件且请求体可重新获取时，才可能重试。

排查时不要只看客户端的“retry=2”日志。把每次尝试的请求方法、URL、ContentLength、是否设置 GetBody 和服务端实际收到的字节数放到同一条关联日志里，才能区分“没有重试”和“重试了但发送空体”。

为什么第二次读取会变空

请求体通常是一个带游标的流。第一次发送会不断调用 Read，游标从开头移动到末尾；第二次把同一个 Body 交给 Transport 时，它已经没有数据可读。Request.Clone 也不会深拷贝 Body，因此只复制 Request 结构体并不能解决问题。

下面这个最小例子故意复用同一个请求，第二次读取会得到空结果。代码中的注释只标出关键的消费点，方便把问题和业务重试代码对应起来：

package main

import (
    "fmt"
    "io"
    "net/http"
    "strings"
)

func main() {
    req, err := http.NewRequest(http.MethodPost, "https://example.com/upload", strings.NewReader("payload"))
    if err != nil {
        panic(err)
    }

    first, _ := io.ReadAll(req.Body)
    second, _ := io.ReadAll(req.Body) // 中文注释：同一个 Body 已在上一次读取到 EOF
    fmt.Printf("first=%q second=%q getBody=%t\n", first, second, req.GetBody != nil)
}

这里的 GetBody 仍可能非空，因为 http.NewRequest 能识别 strings.Reader 等常见 reader。它是“如何创建新 Body”的工厂，不是当前 Body 的游标。真正发起重定向或由 Transport 处理重试时，应该调用这个工厂拿到新的读取对象。

优先让 NewRequest 保存可重放输入

如果请求体来自内存中的字符串或字节，直接把可识别的标准库 reader 交给 http.NewRequest，通常是最小改动。下面的代码使用 bytes.NewReader，每次调用 GetBody 都从同一份不可变字节数据开头创建新的 reader：

package main

import (
    "bytes"
    "fmt"
    "io"
    "net/http"
)

func main() {
    payload := []byte(`{"name":"demo"}`)
    req, err := http.NewRequest(http.MethodPost, "https://example.com/api", bytes.NewReader(payload))
    if err != nil {
        panic(err)
    }

    retryBody, err := req.GetBody()
    if err != nil {
        panic(err)
    }
    defer retryBody.Close() // 中文注释：临时重试 Body 也必须关闭

    got, err := io.ReadAll(retryBody)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(got)) // 中文注释：新 reader 从 payload 的第一个字节开始
}

如果代码只需要跟随 307/308 重定向，保持这种请求构造方式即可；不要在发出第一次请求前手动把 Body 读一遍来“检查内容”，因为那会提前消耗发送对象。需要记录摘要时，基于 payload 计算，而不是读取 req.Body。

自定义流要自己提供 GetBody

文件、压缩流、加密流或实时生成流通常不能让标准库自动推断重建方式。此时先决定业务是否允许重试：如果输入不可重复读取、重试会产生副作用，宁可关闭自动重试或改成幂等协议，也不要伪造一个空的 GetBody。

对可以缓存的输入，可以保留原始字节并显式设置工厂：

package replay

import (
    "bytes"
    "io"
    "net/http"
)

func NewRequest(method, url string, payload []byte) (*http.Request, error) {
    // 中文注释：复制一份输入，避免调用方后续修改影响重试内容
    saved := append([]byte(nil), payload...)
    req, err := http.NewRequest(method, url, bytes.NewReader(saved))
    if err != nil {
        return nil, err
    }

    req.GetBody = func() (io.ReadCloser, error) {
        // 中文注释：每次重试都返回独立 reader，不能复用旧 Body
        return io.NopCloser(bytes.NewReader(saved)), nil
    }
    return req, nil
}

这个模式的代价是内存占用与复制成本。大文件不要为了“让重试成功”盲目全部读进内存，可以使用可定位的文件输入，在每次尝试中重新打开文件并核对文件是否仍然是同一个版本；如果做不到，就把重试边界放在文件上传任务之外。

手工重试时每轮重新创建 Request

业务代码自己循环重试时，最稳妥的规则是：保存请求参数和原始输入，每一轮新建 Request；只复用不可变的配置，不复用已经发送过的 Body。同时，收到响应后先关闭 Response.Body，否则连接复用和资源回收会被拖慢。

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

func postWithRetry(ctx context.Context, client *http.Client, url string, payload []byte) (*http.Response, error) {
    for attempt := 0; attempt 

这个片段省略了重试分类和错误包装，重点是每轮都由同一份 payload 创建新 Body。真实服务还应区分连接错误、429、5xx 和业务拒绝，并确认 POST 是否具有幂等键；请求体可重放不等于业务操作可以安全重复。

两种修复方式怎么选

上线前按这份清单复查

1. 日志能区分首次请求、重定向请求和业务手工重试，并记录尝试次数。
2. 每个可重试请求都能回答“新的 Body 从哪里来”，不能只依赖旧 Body 的当前位置。
3. 对 307/308 检查 GetBody，对 301/302/303 检查方法改变后是否仍符合业务预期。
4. 对 POST、PUT 等写操作确认幂等键、服务端去重或明确的不可重试策略。
5. 每轮完成后关闭响应体；请求体由 Transport 管理，不要在 Do 返回后并发复用同一请求。

如果只记住一句话：重试不是把一个已经走到末尾的流再交给客户端，而是从稳定的原始输入创建一个新的 Body。Go 的 GetBody 解决的是“怎么重新拿到 reader”，幂等键和重试策略解决的才是“这次重复发送是否安全”。

相关问题

• 为什么 strings.Reader 可以自动重试？ 因为 NewRequest 能识别它并生成可复制的 GetBody；自定义 reader 则需要自己提供。
• 把 Body 换成 io.NopCloser 就能修复吗？ 不能。NopCloser 只补 Close 方法，不会保存输入，也不会把游标倒回去。
• GetBody 返回新对象后还要关闭吗？ 要。它返回的对象仍然是 io.ReadCloser，使用完按资源生命周期关闭。