Go http.Request Body 读过一次后为什么下游拿不到

很多开发Go HTTP服务的同学都踩过这个典型的小坑：你在中间件或者前置逻辑里读过一次http.Request的Body之后，下游的业务处理代码再尝试读取Body内容，就只能拿到空结果，拿不到原本的请求数据。

在 Go 的 HTTP 服务里，日志、签名校验或鉴权中间件经常要先读 http.Request.Body。如果读完没有恢复，下游 Handler 再调用 json.Decoder 或 io.ReadAll，常见结果就是读到空内容或 EOF。原因并不是请求体消失了，而是多个读取者共享同一条已经被消费的流。

为什么 Request.Body 读过就到 EOF

io.Reader 表示“从当前位置继续读”，不是可反复读取的字符串。服务端请求中的 Body 类型是 io.ReadCloser；第一次读取会推进内部位置，读到末尾后自然得到 io.EOF。下游拿不到的本质，是前一个读取者已经消费了这条流。

这里要把服务端和客户端分开看。官方文档中的 Request.GetBody 主要用于客户端请求在重定向时重新取得请求体，而且服务端请求不会使用它。因此，在服务端中间件里调用一个并不存在的“回到开头”操作，方向就错了。

中间件读完后怎么恢复给下游

可靠做法是把原始内容暂存为字节切片，然后把 Request.Body 换成基于这份切片创建的新读取器。关键代码如下：

func replayBody(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 先把原始字节保存下来，便于日志或签名逻辑使用。
        data, err := io.ReadAll(r.Body)
        if err != nil {
            // 读取失败时立即结束请求，避免下游拿到半截内容。
            http.Error(w, "request body read failed", http.StatusBadRequest)
            return
        }

        // 用同一份字节创建新的读取流，交还给后续 Handler。
        r.Body = io.NopCloser(bytes.NewReader(data))
        next.ServeHTTP(w, r)
    })
}

如果中间件需要计算摘要或记录审计信息，就对 data 操作，不要再次消耗新的 r.Body。恢复动作必须发生在调用 next.ServeHTTP 之前；否则下游已经开始读了，再替换也来不及。

大请求和读取失败时怎么控制风险

上面的示例适合需要完整缓存请求体的场景，但它会把内容放进内存。生产代码通常先限制大小，再读取：

func replayLimited(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 限制本次中间件最多缓存 1 MiB，避免无界读取占满内存。
        r.Body = http.MaxBytesReader(w, r.Body, 1

相关问题

只读取 JSON 后恢复 Body，还需要重新设置 ContentLength 吗？

服务端下游通常只依赖 Body 读取内容；如果后续逻辑明确依赖长度，再根据字节切片长度更新，但不要把它当成恢复流的替代品。

可以把原来的 Body 保存下来再读第二次吗？

保存旧接口只能保留那条已经前进的流。要重复读取，应保存字节并创建新的 Reader；对大文件或大上传则应改用流式处理，避免完整缓存。

为什么下游有时拿到部分 JSON 而不是 EOF？

这通常说明前置读取者只消费了一部分字节，或者读取过程中发生错误。读取失败必须阻断请求，不能把不完整数据继续交给 JSON 解析器。