Go HTTP 服务端为什么读不到请求体第二次内容

Go HTTP 服务端第二次读不到请求体，通常不是客户端少发了一份数据，而是前一个读取者已经把同一个 Body 消费到了末尾。Request.Body 是读取接口，不是可反复访问的字节数组。想让中间件和业务都读取完整内容，需要先在入口限量保存正文，再为业务建立一个新的读取器。

官方接口说明：https://pkg.go.dev/net/http。下面用一个只统计请求正文长度的小服务说明问题；代码与响应均为教学示例及预期行为，本文没有把它们描述为已执行结果。

1. 先找出谁已经推进了读取位置

设想日志中间件执行了 ReadAll，随后业务处理器又对同一 r.Body 调用 ReadAll。第一次成功时内容保存在第一个返回值里，原流的读取位置已到末尾；第二次成功读取到的通常是空切片，而不是自动回放第一份内容。ReadAll 正常读到末尾会返回 nil 错误，不能把“没有错误”当作“仍有正文”。

排查时，应从最外层中间件查起，查看是否有 ReadAll、JSON 解码器或读取表单的调用。尤其不要只盯着最终 handler。只读了一部分时，后续代码可能得到的是剩余部分；它并不总是空内容，因此更容易误判成字段格式错误。

2. 建立一个中间件和业务都需要正文的小服务

准备带有标准库 net/http 的 Go 环境，把下面完整代码保存为 main.go。端点 /count 只接受 POST：中间件只记录长度，业务返回长度。它不解析 JSON、不做鉴权，也不打印原文，方便把注意力集中到 Body 的所有权上。

package main

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

const maxBody = 1 

核对这一节时，重点看两个不同的读取对象：中间件读取 limited，业务读取 replay。二者处理相同内容，但不是共享同一个游标。仅将 r.Body 赋给另一个变量，或复制 Request 结构体，并不会得到独立正文。

3. 先设置容量边界，再考虑重放

MaxBytesReader 为入口正文设置字节上限，读取超过上限时报告 MaxBytesError。不要先无上限 ReadAll 再判断 len(data)：那时大块内存已经分配过了。Content-Length 也不能代替实际读取限制，因为传输时长度可能未知。

这里将超限返回为 413，其余正文读取失败返回为 400。关键不是错误文字，而是所有失败分支都直接 return；ReadAll 遇到错误时可能带回已读的部分字节，不能把这些片段当成完整请求交给业务。ReadTimeout 与字节限制分别约束时间和体积，均不能承诺整个进程的内存或 CPU 使用上限。

这个方案适合小型接口正文。上传文件或需要流式转发的接口，不应为了统一日志而全部缓存。也不要为了排错将密码、令牌或完整个人资料写入日志。

4. 用新读取器替换字段，不是让网络流倒带

bytes.NewReader(data) 为已有内容建立新的读取位置，io.NopCloser 让它满足 Body 需要的关闭接口。原始 Body 没有被倒带，客户端也没有被要求重发。同一缓存若确实要提供给多个顺序读取者，应各自建立 reader；不要让几个 goroutine 并发争用同一个 Body。

代码单独保存 limited 并延迟关闭，是为了在替换 r.Body 后仍保留原对象的释放路径。HTTP 服务端本身也负责关闭入站请求体；这里显式声明中间件持有对象的生命周期。替代读取器的 Close 不会擦除缓存，缓存只能在没有引用后由垃圾回收处理，因此不要把它留在全局集合中。

把 r.Body 换成新 reader 只保证紧接着的一个消费者可以从头读取。如果业务先 Decode 再交给下一层，而下一层仍需原始正文，必须重新约定重建位置，或者更直接地将已解析的业务对象作为显式参数传递。不要让每个中间件都复制整份数据。

5. 本地运行时应观察哪些响应

读者可在代码目录运行以下命令，再在另一终端发送五字节正文。下列响应是按代码推导的预期结果，不是运行截图或性能测量。

go run main.go # 启动仅监听本机的演示服务
curl -i -X POST --data-binary 'hello' http://127.0.0.1:8080/count # 发送五个 ASCII 字节

预期成功响应正文为 body_bytes=5，中间件记录的 accepted_body_bytes 也应为 5；这说明业务读取的是完整缓存。空正文会得到 body_bytes=0，不代表重建失败；使用 GET 则预期返回 405。读者还可使用大于 1 MiB 的本地测试数据检查 413，确认业务分支没有接收被截断的内容。结束演示后停止本地进程即可。

接入已有项目时，将该中间件放在任何正文消费者之前，并只挂到确实需要重复读取的小请求端点。如果路由原先已解析正文，再加这一层无法找回已经丢弃的字节。示例没有实现压缩正文解码；若另加解压中间件，必须明确限制作用在压缩前还是解压后，并单独设置解压后容量边界。

6. GetBody 为什么不能替服务端自动恢复

Request.GetBody 是可选工厂，主要用于客户端需要重新取得正文副本的场景，服务端入站处理不会自动借助它重放正文。不要直接调用可能为空的 r.GetBody，也不要把它与当前 r.Body 的读取位置混为一谈。

最终应先问：业务真的需要原始字节两遍吗？若需要，入口限量缓存并新建 reader；若只需要相同业务字段，集中解析一次并显式传递对象通常更省内存。无论选择哪条路线，都应让“谁消费原流、谁保存内容、谁创建新游标”在代码中清楚可见。

参考：net/http Request、MaxBytesReader、io.ReadAll。