Go Handler 读取请求体后下游为空的修复方案

这个问题通常不是下游 Handler 把数据“删掉”了，而是前置中间件已经把 r.Body 这条流读到了末尾。修复的首选方案是只让一个组件读取和解码请求体，再把结构化结果传给下游；如果旧接口只能接收 *http.Request，才缓存有限大小的字节并用新的 Reader 重建 r.Body。

先确认是读取权冲突，而不是空请求

服务端请求的 Body 通常不会是 nil；没有内容时，读取会很快到达 EOF。真正容易被忽略的场景是日志、签名校验、鉴权中间件先调用了 io.ReadAll，业务 Handler 随后又从同一个 Reader 读取。Reader 的当前位置不会自动回退，所以后面的 JSON 解码器只能看到空输入。

排查时沿着调用链搜索所有 Read、ReadAll、Decode、ParseForm 和 MultipartReader。同一个请求体最好只指定一个读取者；不要把“下游为空”简单归因于客户端没有发送数据。

新代码：解析一次，把 Payload 交给下游

当中间件和业务代码都由你维护时，最稳妥的边界是让入口负责读取、限制和解码，后续函数接收 Payload。这样下游不依赖 Body 的当前位置，也不会因为某个日志分支多读一次而改变业务结果。

type Payload struct {
	Name  string `json:"name"`
	Count int    `json:"count"`
}

func decodePayload(w http.ResponseWriter, r *http.Request) (Payload, error) {
	var p Payload
	// 先限制输入上限，再只解码一次，避免无界读取请求体。
	limited := http.MaxBytesReader(w, r.Body, 1

这里的重点不是把所有逻辑都塞进中间件，而是明确“谁消费流、谁使用结果”。如果业务还需要原始字节，可以在入口读取一次后同时传递 []byte 和解析结果，但要注意不要让多个函数各自重新读取。

兼容旧下游：缓存后重建 Body

如果下游是只接受 *http.Request 的旧 Handler，或者签名校验完成后仍要让框架绑定器重新读取，就在边界处保存有限大小的字节，再把新的 Reader 放回请求。重建后的 Body 只是同一份内存数据的再次读取，不会让原始网络流倒带。

func replayBody(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		original := r.Body
		// 将最大缓存限制在 1 MiB，避免把大请求直接全部放进内存。
		limited := http.MaxBytesReader(w, original, 1

这个方案适合迁移期或少量小请求。它会把请求体完整保存在内存里，不能替代真正的流式上传处理；文件上传、超大 JSON 或不可信客户端场景应改用更明确的流式协议和大小限制。

把 Body 生命周期和格式边界写进检查清单

还要留意空请求和格式错误不是一回事：空 Body 可能是客户端协议允许的情况，JSON 语法错误则应明确拒绝；读到一段合法 JSON 后还有第二个值，也不应悄悄忽略。对于敏感数据，日志不要保存完整原文，重放缓存也要设定生命周期。

常见问题

把 r.Body 赋回 bytes.NewBuffer 后就一定安全了吗？

只对小而有上限的请求安全。没有大小限制时，重置 Body 可能放大内存风险；而且它只能重放已经读入内存的内容。

调用 r.ParseForm 后还能让下游再次读取表单吗？

不要假设可以。把解析后的 r.Form 或 r.PostForm 作为结果传下去；若旧接口必须重读，仍需明确缓存并重建 Body。

为什么读取后只剩半段内容？

读取错误可能发生在已返回部分字节之后。应先处理错误，再决定是否丢弃这次请求，不能把不完整缓冲区当作有效 JSON 交给业务。

一句话收束：请求体是流，不是可随意复制的字符串。把读取权固定在一个边界，优先传结构化结果；只有兼容旧 Handler 时才受限缓存并重建 r.Body。