Go 请求体被读取后再次读取的恢复处理

Go 的 Request.Body 是有读取位置的流。中间件读完后，下游再次读取通常只会遇到EOF。要让下游重新读取，应在第一次消费时完整且有界地保存原始字节，再用 io.NopCloser(bytes.NewReader(raw)) 替换Body。已经读走又没有保存的内容，不能靠重新赋值或修改ContentLength恢复。

官方地址：https://pkg.go.dev/net/http#Request

我会先比较两个数量：预读阶段获得多少字节，下游实际得到多少字节。若输入非空、预读完整而下游为零，优先检查读取器的交接，而不是先怀疑JSON结构。下面用小型请求预读作为设计场景，给出判断方法和资源成本；不把假设数据写成线上经历或压测结果。

先找到第一个消费Body的组件

原始流只有一个当前位置。io.ReadAll、JSON解码器、表单解析器以及自行读正文的中间件都可能推进位置；把同一个Reader交给另一个函数不会自动回到起点。

排查时可以记录阶段名称、读取错误和字节数量，避免打印请求正文。EOF有时只是空请求的正常结尾，因此必须区分“客户端本来没有正文”与“正文已被前置组件耗尽”。不能只看到EOF就返回内部错误。

如果第一个组件没有保留已读数据，恢复工作的正确位置在那个组件之前。后来拿到的只剩尾部流，即使成功ReadAll，也只会缓存剩余部分。

用有界缓存交给下游一个新Reader

下面的中间件在调用下游之前读取完整小请求。128 KiB是示例预算，普通读取错误返回400，超限返回413；这两类情况都不继续执行下游。代码用于接入现有HTTP服务，没有在本文环境执行。

package replay

import (
    "bytes"
    "errors"
    "io"
    "log"
    "net/http"
)

// ReplaySmallBody只用于需要预读的小请求，必须放在其他正文消费者之前。
func ReplaySmallBody(next http.Handler) http.Handler {
    const limit int64 = 128 

bounded 保存原始流的包装器，函数结束时关闭它；Body后来被替换，也不会丢失这项清理责任。新Body只包住内存读取器，NopCloser为它补上无操作的Close方法，不负责关闭原始网络流。

示例没有改写ContentLength，也没有修改请求内容。服务端请求的长度声明并不能把耗尽的Body重新填满；恢复的依据是完整缓存的原始字节。对于转发到另一个服务的新请求，应单独构建客户端请求，按实际正文设置元数据，不能直接照搬这里的服务端处理方式。

新Reader有新偏移，缓存仍然要保持只读

bytes.NewReader(raw) 建立独立读取位置，但不会因此产生一份独立正文副本。若两位消费者都需要从头读取，应分别新建Reader，而不是让他们顺序共享一个已经耗尽的Reader。

两次创建的Reader可以引用同一份只读缓存；处理期间修改raw会影响读到的内容，也可能造成并发访问问题。需要修改数据的组件应获得独立副本。本文示例只把原字节交给下游，没有设计多个协程同时读取同一个Body。

如果下游的另一个中间件也要预读，它也必须遵守交接约定，或者更合理地共享统一的受控缓存接口。一次恢复只保证下一位消费者有机会读取，不会让Body变成无限次自动回放的对象。

为什么服务端不能直接依赖GetBody？

官方把 GetBody 定义为可选的正文副本获取函数，用于客户端重定向等需要重读正文的场景；服务端请求不使用它。收到的入站请求不能假定GetBody已经设置，更不能直接调用一个nil函数。

即使应用自行设置了GetBody，也不等于自动替换当前Body。它表达的是创建另一份读取器的能力；消费者仍需明确获取和使用那个读取器。客户端构造请求时，某些内存Reader类型可让标准库填充GetBody，但这不代表网络上传来的服务端请求也具备同样条件。

Request.Clone 也不能当作正文复制器。不要把复制请求对象和复制正文数据混为一谈：需要重读的是字节流，必须有可重新打开的数据来源。

用完整性指标和容量预算决定是否采用

对于长度为B的请求，完整缓存会保留约B字节的正文数据；ReadAll扩容、解析对象和日志队列等可能增加额外成本。若C个请求同时驻留，单是正文保留量就约为C×B。这是容量估算，不是堆内存的精确上限，也不是实测结果。

我只会把这种方式用于明确需要预读且容量受控的小请求。大上传应考虑一次解析、多组件共享解析结果，或有容量、生命周期和清理约定的临时文件方案。只做长度记录的服务其实无需完整缓存，本文长度日志只是预读操作的简化占位，不应为它单独引入全量读取。

这张表是项目回归设计，不是已运行的测试报告。评估成本时应在相同输入、并发和下游工作量下比较延迟、每请求分配量与峰值内存，不能仅凭减少一次JSON错误就宣称性能提升。

相关问题

直接Seek到0可以吗？

只有具体底层对象支持Seek且你明确持有它时才可使用。Request.Body只保证ReadCloser接口，不保证网络请求体可以定位；通用中间件不能依赖这一点。

TeeReader能自动重读吗？

不能。它在读取过程中把数据同步写入另一个Writer，仍需保存足够的数据并建立新的读取器。下游只读取了一部分时，缓存也可能只有前缀。

把JSON重新序列化回Body可以吗？

这会改变字节表示，字段顺序和空白等可能不同。若业务依赖原始字节或正文签名，应保存和回放原始数据，不能把解析后的对象当成原文副本。

我的取舍是把“是否需要读第二遍”作为接口约定：能一次消费就避免缓存；确实需要预读时，从首次读取处保存完整有界字节，让每位消费者明确获得自己的读取位置。

参考：Request字段语义；NopCloser接口适配；内存字节读取器。