Go http.Request.GetBody 为什么重定向重试时很重要

给 Go 的 http.Client 发带 body 的 POST 请求时，第一次发送成功并不代表后续重定向还能把 body 原样带上。Request.Body 是一次性读取流，而 Request.GetBody 是“需要再发一次时，如何重新创建一份 body”的工厂函数。对 307、308 重定向尤其如此：它们要保留原方法和请求体，客户端只有在 GetBody 可用时才有可靠的重放入口。

Body 为什么不能直接拿来重试

Body 的类型是 io.ReadCloser，Transport 发送请求时会持续读取它。读到末尾后，原来的读取位置已经改变；即使底层数据来自内存，也不能把同一个 reader 当成一份新的 body。简单地再次调用 Do(req)，并不会自动把已经读完的流倒回开头。

GetBody 不保存“当前游标”，而是每次返回一个新的 io.ReadCloser。因此它适合表达可重复发送的字节快照，不适合把摄像头、管道、压缩实时流或已经消耗的网络流强行标记为可重放。

307 和 308 为什么更依赖 GetBody

Go 官方 net/http 文档把重定向分成两种语义。301、302、303 在允许跟随时会把后续请求改为 GET（原请求为 HEAD 时为 HEAD），并且不带原 body。307、308 则要求保留原 HTTP 方法和 body；如果客户端无法通过 GetBody 创建下一份 body，就没有安全的重放条件。

这也是“浏览器能跳转、Go 请求却像少了数据”的常见原因：服务端返回 307/308，客户端确实需要再次发送 POST 内容，但你传入的是没有重建能力的流。此时先看重定向状态码，再看 req.GetBody == nil，比盯着服务端业务日志更快。

NewRequest 自动做了什么

用 http.NewRequest 创建客户端请求时，标准库能识别 *bytes.Buffer、*bytes.Reader 和 *strings.Reader。它会记录准确的 ContentLength，并填充可重新生成 body 的 GetBody。这类写法通常已经覆盖 JSON、表单或小型文本请求：

package main

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

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

    // bytes.Reader 可被标准库识别，因此 307/308 重定向有重建 body 的入口。
    fmt.Println(req.ContentLength, req.GetBody != nil)
}

相反，若把同一份数据包进自定义 io.ReadCloser、管道或网络流，标准库无法猜测它能否再次读取，GetBody 往往为空。这里不是“少调用了一个初始化函数”，而是数据源本身可能没有第二份内容。

自定义请求体怎么补上 GetBody

如果请求体本来就是可控的小型字节数据，可以先保存快照，再让每次 GetBody 从快照创建新的 reader：

payload := []byte(`{"event":"created"}`)
req, err := http.NewRequest(http.MethodPost, endpoint, io.NopCloser(bytes.NewReader(payload)))
if err != nil {
    return err
}

// 每次返回新的读取器，不能复用第一次发送过的 Body。
req.GetBody = func() (io.ReadCloser, error) {
    copyOfPayload := append([]byte(nil), payload...)
    return io.NopCloser(bytes.NewReader(copyOfPayload)), nil
}
req.ContentLength = int64(len(payload))

resp, err := client.Do(req)
if err != nil {
    return err
}
// 读完并关闭响应体，给 Transport 留出连接复用机会。
defer resp.Body.Close()

这个方案的边界很明确：它把 body 全部放在内存里，适合小 JSON 或有限长度的表单，不适合超大上传。大文件可以使用可定位文件并在工厂里重新打开，也可以关闭自动重定向，拿到 307/308 后由业务层决定是否重新获取数据；对于不可重复的实时流，则不应伪造 GetBody。

排查重定向重试的四项检查

• 记录响应状态码和 Location，先确认是 301/302/303 还是 307/308。
• 在发送前检查 req.GetBody 是否为空，不要等业务端收到空 body 才猜原因。
• 确认重定向目标是否可信；自动跟随重定向还会涉及 Cookie、Authorization 等敏感头的转发边界。
• 确认响应体被读取并关闭；这与请求体能否重放是两件事，但会影响连接复用。

常见问题

GetBody 设置了，Body 还需要设置吗？

需要。GetBody 只负责后续重建，第一次发送仍然读取 Body。

所有重试都必须设置 GetBody 吗？

不是。GET 等无 body 请求不需要它；Transport 对网络错误的内部重试也有幂等性和 body 条件，不能把“设置 GetBody”当成通用重试授权。

能不能在 GetBody 里返回同一个 Body？

不建议。返回同一个已经被读取或可能并发读取的对象会把重试变成空 body、错位读取或资源竞争，应当每次创建新的读取器。