Go HTTP 重试时 GetBody 为什么为空

我在给一个带 JSON 请求体的 Go 客户端加重试时，最先遇到的不是网络错误，而是 req.GetBody == nil。这个结果通常不是 net/http 丢了数据，而是创建请求时传入的 reader 类型没有提供“如何重新创建一份 body”的信息。

结论：只要请求体来自自定义 io.Reader，就不要假设 GetBody 会自动出现。把原始 payload 保存在不可变的 []byte 中，再让 GetBody 每次返回新的 io.ReadCloser，才能支持显式重试。

官方地址：https://pkg.go.dev/net/http#Request

先分清 Body、GetBody 和重试是谁在使用

Request.Body 是当前这一次发送要读取的请求体；客户端传输层读取它之后，读指针就已经向前移动。Request.GetBody 是一个可选函数，职责是返回一份新的 body 副本。它不是“当前 body 的缓存”，也不会因为 Body 被读过就自动把内容倒回去。

标准库文档把 GetBody 的主要用途描述为客户端请求在重定向时需要再次读取 body。对 307 和 308，HTTP 客户端需要保留原方法和请求体；这时如果没有可用的 GetBody，请求就没有可靠的重放来源。业务代码里的“失败后再试一次”则不会因为设置了 GetBody 就自动发生，重试循环仍然需要自己调用它并创建下一次请求。

为什么传入自定义 reader 后 GetBody 会为空

http.NewRequest 接收的是 io.Reader，但它不能从任意 reader 推断出“如何从头重新读取”。官方实现只对 *bytes.Buffer、*bytes.Reader 和 *strings.Reader 做了特殊处理：记录准确长度，并设置一个能重新创建 body 的 GetBody。

下面这个例子故意把 bytes.Reader 包进 io.NopCloser。虽然底层仍然是字节数据，但传给 NewRequest 的动态类型已经不是它自动识别的三种类型，所以 GetBody 会保持为空：

package main

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

func main() {
    payload := []byte(`{"name":"go"}`)

    // 包装后传入的是 io.ReadCloser，NewRequest 无法推断重建方式。
    body := io.NopCloser(bytes.NewReader(payload))
    req, err := http.NewRequest(http.MethodPost, "https://example.com/items", body)
    if err != nil {
        panic(err)
    }

    // 这里为 false 是正常结果，不代表 Request.Body 没有内容。
    fmt.Println(req.Body != nil, req.GetBody != nil)
}

对比之下，直接传入标准库认识的类型即可自动获得 GetBody：

payload := []byte(`{"name":"go"}`)

// bytes.NewReader 保留了长度和起始位置，NewRequest 可以复制它的读取状态。
req, err := http.NewRequest(http.MethodPost, "https://example.com/items", bytes.NewReader(payload))
if err != nil {
    return err
}

// 对标准 reader 类型，GetBody 通常会被自动填充。
if req.GetBody == nil {
    return errors.New("request body cannot be replayed")
}

这里的关键不是“必须使用 bytes.Reader”，而是请求构造阶段必须同时拥有原始数据和可重建规则。文件流、压缩流、加密流或一次性生成器通常无法被安全地自动复制，框架选择留空比猜测更可靠。

最小配方：用不可变 payload 显式补上 GetBody

如果请求体来自自定义编码器，最稳妥的做法是先完成编码，把结果保存为一份不会在重试之间改变的字节数据。然后让工厂每次从这份数据创建新的 reader 和 closer。注意，GetBody 返回的不是同一个已读过的 Body，而是新的读取对象。

package client

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

func newReplayableRequest(method, url string, payload []byte) (*http.Request, error) {
    // 复制一份输入，避免调用方后续修改切片导致重试内容变化。
    snapshot := append([]byte(nil), payload...)

    // 每次调用都创建新的 reader 和 ReadCloser，不能复用已经读过的对象。
    newBody := func() io.ReadCloser {
        return io.NopCloser(bytes.NewReader(snapshot))
    }

    // 第一次发送也使用同一个工厂，Body 与 GetBody 的来源保持一致。
    req, err := http.NewRequest(method, url, newBody())
    if err != nil {
        return nil, err
    }
    req.GetBody = func() (io.ReadCloser, error) {
        return newBody(), nil
    }
    req.ContentLength = int64(len(snapshot))
    return req, nil
}

这个写法解决了三个容易混在一起的问题：请求体有稳定快照、每次读取都从零开始、ContentLength 与实际 payload 一致。若 payload 很大，不要为了重试盲目复制多份内存，可以改用可重新打开的临时文件或其他明确支持重复读取的存储，并把生命周期和并发访问写清楚。

307/308 跳转与业务重试要分开处理

设置了 GetBody，只说明请求具备“重新取一份 body”的能力，不等于所有失败都会自动重试。HTTP 客户端的重定向策略和业务重试策略是两层机制。

如果是 307 或 308 重定向，客户端需要保留原方法和 body；使用 NewRequest 创建的标准 reader 可能已经自带 GetBody。如果是 500、超时或连接暂时失败后的业务重试，应由代码明确判断错误是否值得重试，再用工厂创建新的请求。

func doWithRetry(client *http.Client, method, url string, payload []byte) (*http.Response, error) {
    snapshot := append([]byte(nil), payload...)

    for attempt := 0; attempt 

上面的显式重试直接从快照新建请求，因此不依赖 GetBody。如果你的重试抽象已经拿到一个 *http.Request，则可以调用 req.GetBody()，把返回值放到一个新 Request 的 Body 中；不要调用同一个 Body 的 Read 指望它自动回到起点。

几个容易踩中的边界

我会怎样判断这次修复是否合适

我通常先问三个问题：请求体能否从一个稳定快照重新生成？重试是否真的值得承担重复写入风险？每一次尝试是否有独立的 Body 和明确的关闭责任？三个问题只要有一个答不上来，就不应该仅仅把 GetBody 从 nil 改成非 nil。

对于幂等的查询、明确支持幂等键的写入请求，有限次数的重试更容易控制。对于一次性流、带副作用的 POST、或无法确认服务端是否已经收到请求的超时，宁可把重试条件收窄，也不要用一个“万能 body 重放器”掩盖业务语义。

相关问题

GetBody 不为空，为什么业务重试还是没有发生？

因为 GetBody 只提供重建 body 的能力，不会替你决定哪些错误可重试，也不会自动循环调用 Client.Do。

把 Request.Body 重新赋值为同一个 reader 可以吗？

通常不可以。reader 可能已经处在 EOF，应该从不可变快照或可重新打开的源创建新的读取对象。

为什么用 io.NopCloser 包一层就失去自动 GetBody？

NewRequest 的自动处理看的是传入值的具体类型。包裹后类型信息不再是它特殊识别的几种 reader，因此需要显式设置工厂。

服务端收到的 Request 也要设置 GetBody 吗？

不需要。GetBody 是客户端请求的可选重放函数，服务端 Request 的 body 由服务器处理生命周期，二者用途不同。