Go http.Request.GetBody 为什么不是所有请求都有：重试读取、流式上传与内存边界

线上请求签名需要重算，或者客户端遇到 307 重定向要再次发送请求体时，很多 Go 开发者会顺手写下 req.GetBody()。结果往往不是“请求体为空”，而是这个函数根本没有被设置。关键点在于：GetBody 不是所有 io.Reader 都能自动复制，它只代表当前请求是否保留了一个安全、可重复创建的请求体来源。

把请求体包装成可重读的内存或文件来源时，才适合用 GetBody 做重试；真正的流式上传应在业务层决定缓存、落盘或禁止重试。

先把 GetBody 和 Body 分开看

Request.Body 是当前这一次读取使用的 io.ReadCloser。读取一次以后，游标通常已经走到末尾。Request.GetBody 的签名则是 func() (io.ReadCloser, error)，它的含义是重新创建一个新的 Body，供重定向、客户端认证或签名流程再次读取。

body := strings.NewReader(`{"name":"gopher"}`)
req, err := http.NewRequest(http.MethodPost, "https://api.example.test/items", body)
if err != nil {
    log.Fatal(err)
}

if req.GetBody == nil {
    log.Fatal("request body cannot be recreated")
}

copyBody, err := req.GetBody()
if err != nil {
    log.Fatal(err)
}
defer copyBody.Close()

这里的 copyBody 和原来的 req.Body 是两次独立读取。调用 GetBody 不会把已经消耗的当前 Body 倒回去，也不会替你关闭原来的 Body。

哪些请求会自动拥有 GetBody

使用 http.NewRequest 创建请求时，标准库能识别一小组常见的、可以从固定数据重新开始的 Reader，例如 *bytes.Buffer、*bytes.Reader 和 *strings.Reader。这类来源的长度也更容易确定，客户端可以同时设置合理的 ContentLength。

换成自定义 io.Reader、网络管道或一次性解压流后，库没有办法猜出“如何重新得到同一批字节”。即使这个 Reader 眼下能读完，也不等于它能在下一次请求中生成相同内容。

var stream io.Reader = os.Stdin
req, err := http.NewRequest(http.MethodPost, endpoint, stream)
if err != nil {
    return err
}
// 对任意 io.Reader，不要假设 req.GetBody 一定非空。
if req.GetBody == nil {
    return errors.New("stream body is not replayable")
}

判断要放在真正需要重读之前，而不是等客户端已经收到网络错误后才补救。对于不允许重试的上传接口，发现为空也可以是预期结果。

把一次重试流程拆成四个检查点

需要重试时，建议把流程写成四个明确的阶段：确认请求方法和幂等策略、确认请求体可以重建、重新计算依赖 Body 的签名、最后才创建并发送新的请求。不要直接复用已经读过的 req.Body。

func replayBody(req *http.Request) (io.ReadCloser, error) {
    if req.GetBody == nil {
        return nil, errors.New("body has no replay source")
    }
    return req.GetBody()
}

func signReplay(req *http.Request) (string, error) {
    body, err := replayBody(req)
    if err != nil {
        return "", err
    }
    defer body.Close()

    sum := sha256.New()
    if _, err := io.Copy(sum, body); err != nil {
        return "", err
    }
    return hex.EncodeToString(sum.Sum(nil)), nil
}

示例中的签名只展示读取边界。真实重试还要结合状态码、超时发生阶段和服务端是否可能已经落库。连接断开并不等于服务端没有收到请求，支付、写订单等操作尤其不能只凭网络错误盲目重发。

流式上传为什么通常不适合强行补 GetBody

一个几 GB 的文件如果先全部读入内存，只为了让 GetBody 非空，代价很快会变成堆峰值、GC 压力和多个并发上传同时失败。若把流复制到临时文件，重试能力变好了，但也新增了磁盘配额、清理时机和敏感数据落盘风险。

因此可以按来源做选择：小请求体直接保存在有界内存中；大文件先落盘并记录大小和校验和；来自管道或实时采集的数据则关闭自动重试，把失败交给上游重新产生一份数据。这个判断比“给所有请求都填一个 GetBody”更可靠。

const maxReplayBytes int64 = 2  maxReplayBytes {
        return nil, errors.New("body exceeds in-memory replay limit")
    }
    return func() (io.ReadCloser, error) {
        return os.Open(path)
    }, nil
}

这段策略只是示意：生产代码还应核对文件是否仍属于同一版本，并在请求完成或取消时清理临时文件。重试的“可用”必须包含数据一致性和资源回收。

常见误区与一个可落地的速查表

• 把 GetBody 当成当前 Body 的 rewind：应改为调用它创建新的 Reader。
• 看到 http.NewRequest 成功就认为可重试：还要检查 req.GetBody != nil。
• 为了重试无界缓存上传：给内存、磁盘和并发数设置上限。
• 网络超时后无条件重发写请求：先确认服务端幂等键或业务去重方案。

可以把最终判断压缩成一句话：数据来自可重复读取的固定来源，且重放成本在预算内，才启用 GetBody；数据来自一次性流，或重放会放大副作用，就在协议和业务层明确“不自动重试”。

相关问题

GetBody 调用后需要关闭返回值吗？

需要。它返回的是新的 io.ReadCloser，使用完应立即关闭，不能只关闭原来的 req.Body。

服务端收到的 Request 也能依赖 GetBody 吗？

不能把它当成服务端请求体缓存。服务端通常只提供当前到达的 Body；如果业务需要验签后再解析，应在有界条件下缓存或把读取结果交给后续处理。

重试请求一定要重新计算签名吗？

只要签名覆盖请求体、长度或相关头部，就应基于本次重建的字节重新计算，并同时检查服务端是否支持幂等重试。

把这几个边界提前写进请求封装，遇到重定向、验签或短暂网络故障时，问题会从“Body 怎么又空了”变成一组能验证的条件。