Go http.Request Body GetBody 什么时候会自动可用

很多人第一次看到 http.Request.GetBody，会把它理解成“读取过 Body 后再读一次”的备用接口。这个理解只对了一半：GetBody 是客户端请求的可选重建函数，服务端收到的请求不会靠它重复读取。用 http.NewRequest 创建客户端请求时，*bytes.Buffer、*bytes.Reader 和 *strings.Reader 这三类标准 reader 会自动得到它；普通自定义 io.Reader 则不会。

先把客户端请求和服务端请求分开

Request.Body 和 Request.GetBody 的名字很像，职责却不一样。Body 是当前这次请求实际要读的 io.ReadCloser；GetBody 是一个可选函数，调用后应返回另一份全新的 io.ReadCloser。它不是“把已经读完的 Body 倒回去”，而是“知道原始数据在哪里，再构造一个新的读取器”。

在客户端侧，http.Client 处理 307 或 308 重定向时，需要继续使用原方法和原请求体；传输层遇到满足条件的网络错误时，也可能需要重试。此时只有 GetBody 已定义，客户端才有机会取得新 Body。301、302、303 通常会改用 GET 或 HEAD，不属于同一类 Body 重放问题。

在服务端侧，handler 拿到的 Request 表示已经到达服务器的入站请求。官方文档明确说明，服务端的 GetBody 不使用；handler 应直接读取 Body，必要时在读取前用 http.MaxBytesReader 或其他上限约束输入。

NewRequest 会自动支持哪些 Body 类型

下面的实验不需要真正发出网络请求，只观察 NewRequest 组装后的字段。关键是把“reader 的具体类型”传给标准库，而不是只看它是否实现了 io.Reader：

package main

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

func main() {
    // 三种标准 reader 都保留了可重新定位或可重新构造的原始数据。
    bodies := []struct {
        name string
        body any
    }{
        {"bytes.Buffer", bytes.NewBufferString("name=go")},
        {"bytes.Reader", bytes.NewReader([]byte("name=go"))},
        {"strings.Reader", strings.NewReader("name=go")},
    }

    for _, item := range bodies {
        // NewRequest 识别具体类型后，才会自动设置 ContentLength 和 GetBody。
        req, err := http.NewRequest(http.MethodPost, "https://example.com/echo", item.body.(interface{ Read([]byte) (int, error) }))
        if err != nil {
            panic(err)
        }
        fmt.Printf("%s: length=%d, getBody=%t\n", item.name, req.ContentLength, req.GetBody != nil)
    }
}

这里的打印重点不是具体数字，而是 getBody=true。标准库还会根据长度处理空 Body；这正是 NewRequest 能做到的“有来源可重建”。若把同样的数据先包进一个普通的自定义 reader，具体类型信息丢失后，自动填充也就不会发生。

普通自定义 Reader 为什么拿不到 GetBody

实现 Read 只代表“现在能给出下一段数据”，没有承诺“以后还能从头给出一份相同数据”。例如压缩流、网络管道、加密流和从设备读取的 reader，都可能无法安全复制。让 NewRequest 对所有 io.Reader 自动生成 GetBody，反而会隐藏数据不一致、内存暴涨或外部资源重复消费的问题。

服务端测试还容易造成另一个误会。httptest.NewRequest 创建的是适合 handler 的入站请求，即使传入了 bytes.Reader，也不能据此推断生产 handler 会拥有可用的 GetBody。测试应覆盖 handler 对 Body 的读取、大小限制和错误处理，而不是把 GetBody 当作第二遍输入。

func readOnce(w http.ResponseWriter, r *http.Request) {
    // 服务端只从当前 Body 读取，并限制本次请求的最大输入。
    r.Body = http.MaxBytesReader(w, r.Body, 1

示例省略了导入列表，但保留了三个关键判断：限制输入、处理读取错误、把读出的字节交给业务逻辑。代码中的 io.ReadAll 适合小请求；大请求应改成流式处理或先写入受控临时文件。

需要重放时，显式提供一个新的 Body

如果请求体确实来自内存字节，并且业务允许复制，就把原始字节保存下来，同时为每次调用返回新的 reader。注意 GetBody 返回的是新对象，不能把同一个已经读过的 Body 再返回：

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

// 用原始字节作为唯一来源，后续每次都创建独立 reader。
req, err := http.NewRequest(http.MethodPost, "https://example.com/echo", bytes.NewReader(payload))
if err != nil {
    return err
}

// 自定义 Body 时显式声明如何重建；返回值必须是全新的可关闭 reader。
req.GetBody = func() (io.ReadCloser, error) {
    return io.NopCloser(bytes.NewReader(payload)), nil
}

// Body 仍然要保留，GetBody 不能替代本次发送所需的 Body。
resp, err := http.DefaultClient.Do(req)
if resp != nil {
    // 客户端响应体由调用方关闭，避免连接无法复用。
    defer resp.Body.Close()
}
if err != nil {
    return err
}

文件或对象存储输入则不应盲目把全部内容读入内存。可以在 GetBody 中重新打开同一个只读文件，并让返回的 reader 负责关闭文件；前提是文件在整个重定向或重试窗口内保持可访问，而且内容不会被并发修改。若请求带有一次性签名、随机 nonce 或不可重复的外部副作用，宁可关闭自动重放，也不要为了让函数非空而复制一份看似相同的 Body。

发布前的四项判断

• 来源：这是客户端用 NewRequest 构造的请求，还是服务端 handler 收到的入站请求？
• 类型：Body 是否是 *bytes.Buffer、*bytes.Reader 或 *strings.Reader，还是一个无法回退的普通流？
• 场景：是否真的需要 307/308 重定向或传输层重试？不需要时，不必为 GetBody 增加复杂缓存。
• 资源：每次 GetBody 是否返回新 reader，文件、响应体和临时资源是否都有明确关闭责任？

相关问题

GetBody 不为空，是否代表 Body 可以读两次？

不是。当前发送仍使用 Body；需要第二份内容时应调用 GetBody 得到新的 reader，不能重复读取同一个 Body。

为什么给请求包一层 io.NopCloser 后自动能力消失？

因为 NewRequest 识别的是具体的三种 reader 类型。包裹后可以继续传输，但标准库无法从任意 io.ReadCloser 推断如何重新生成内容；需要时手动设置 GetBody。

服务端想记录请求体，应该调用 GetBody 吗？

不应该。先限制大小，再读取一次并按需把字节交给日志或业务层；敏感字段还要脱敏，避免为了“可重读”长期保留完整 Body。