当前位置：首页 > 文章列表 > Golang > Go问答 > Go http.Request.GetBody 为什么重定向重试时很重要

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

来源：17golang原创 2026-10-05 01:15:11 0浏览收藏

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

要点速览

301、302、303 通常转成无 body 的 GET；不能用它们判断 POST body 是否被重放。
307、308 保留原方法和 body，但 body 能否重读取决于 GetBody。
NewRequest 对 bytes.Buffer、bytes.Reader、strings.Reader 等常见类型会自动设置 GetBody，自定义流式 reader 需要自己决定是否支持重放。

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

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

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

Go http.Request 的 Body 一次性流与 GetBody 新建请求体工厂关系说明图 — 图1：结构说明图，展示 Request.Body、GetBody 工厂和新的独立请求体之间的静态关系。

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，比盯着服务端业务日志更快。

状态码	后续方法	请求体判断
301/302/303	GET 或 HEAD	原 body 不随新请求发送
307/308	保留原方法	需要可用的 GetBody 才能重放

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 往往为空。这里不是“少调用了一个初始化函数”，而是数据源本身可能没有第二份内容。

Go 307 308 重定向保留方法请求体与 GetBody 边界说明图 — 图2：结构说明图，展示重定向状态码、方法保留规则和 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。