req.Body只能读一次是因为其底层是不可重置的io.ReadCloser，Go标准库未缓存请求体以避免内存浪费和适配流式处理；常见解法是用io.ReadAll读取后通过bytes.NewReader和io.NopCloser重建可重读Body，或使用req.GetBody（需预先设置）。
为什么 req.Body 只能读一次
HTTP 请求体（req.Body）本质是一个 io.ReadCloser，底层通常指向一个网络连接或内存缓冲区。Go 的 http.Request 设计上不缓存原始 Body 数据——读完就丢，没有 rewind 机制。这不是 bug，是刻意为之：避免内存膨胀、减少中间拷贝、适配流式处理场景。
常见错误现象：io: read/write on closed pipe、空 JSON 解析结果、json: cannot unmarshal object into Go value of type string（实际是读到了空字节），往往是因为在中间件或日志里提前调用了 io.ReadAll(req.Body)，后续业务逻辑再读就啥都没了。
- 所有基于
req.Body的操作（json.NewDecoder(req.Body).Decode()、io.ReadAll()、form.Parse()）都会消耗流 -
req.ParseForm()和req.FormValue()内部会自动读 Body（如果是 POST 表单），触发一次消耗 - 即使你只调用了一次
req.Body.Close()，也会导致后续读取失败（虽然通常不手动 Close，但某些封装库会）
用 req.Body = ioutil.NopCloser(bytes.NewReader(buf)) 复制 Body
最常用也最可控的解法：把原始 Body 全量读进内存，再用 bytes.Reader 包一层，反复提供可重读的副本。注意 Go 1.16+ 已将 ioutil 合并进 io，应改用 io.ReadAll + bytes.NewReader。
使用场景：需要多次解析（如先验签再解密再反序列化）、中间件记录原始请求体、调试时打印 Body 内容。
立即学习“go语言免费学习笔记（深入）”；
buf, err := io.ReadAll(req.Body)
if err != nil {
http.Error(w, "read body failed", http.StatusBadRequest)
return
}
// 恢复 Body，供后续 handler 使用
req.Body = io.NopCloser(bytes.NewReader(buf))
// 现在可以安全地多次读了
json.NewDecoder(req.Body).Decode(&v1)
req.Body.Close() // 注意：必须关，否则下个 handler 会因已关闭报错
req.Body = io.NopCloser(bytes.NewReader(buf)) // 再次恢复
json.NewDecoder(req.Body).Decode(&v2)
- 务必检查
err，Body 可能为空或超大（没做限制时易被攻击） - 恢复 Body 后，别忘了在每次读完后
req.Body.Close()，否则后续req.ParseMultipartForm()等会失败 - 不要省略
io.NopCloser——bytes.Reader不实现io.Closer，而req.Body类型要求是io.ReadCloser - 大文件上传场景慎用，可能 OOM；此时应改用临时文件或流式校验
用 req.GetBody 替代手动复制（推荐用于标准库兼容）
Go 1.8+ 在 http.Request 中加了 GetBody 字段，类型为 func() (io.ReadCloser, error)。如果服务端自己设置了它（比如用 httputil.NewSingleHostReverseProxy 时会自动设置），就可以直接调用获取新 Body 实例，无需手动读内存。
使用场景：代理服务、需要与标准库行为对齐的中间件、不想管理 buf 生命周期。
- 默认情况下
req.GetBody是nil，必须显式设置才有效 - 如果你控制请求来源（比如测试构造
http.Request），可在创建时赋值：req.GetBody = func() (io.ReadCloser, error) { return io.NopCloser(bytes.NewReader(buf)), nil } - 第三方框架（如 Gin）内部会设置
GetBody，所以c.Request.GetBody()通常可用，但需确认版本 - 依赖
GetBody的代码更“标准”，但灵活性不如手动复制：无法动态修改内容、不能插入日志逻辑
哪些情况根本不需要重复读 Body
很多问题其实源于设计误判。Body 只读一次不是缺陷，而是提示你该调整数据流结构。
常见可规避场景：
- 验签和业务逻辑分离：把签名头（如
X-Signature）和 Body 内容一起哈希，而不是反复读 Body；或者只对关键字段签名，解析一次后取字段计算 - 日志中间件：用
io.TeeReader边读边写到bytes.Buffer，而不是全量读完再恢复 —— 更省内存且顺序明确 - 表单提交：优先用
req.PostFormValue("key")，它会自动调用ParseForm并缓存结果，后续调用不重复读 Body - 文件上传：用
req.MultipartReader()流式处理，避免一次性加载整个文件
真正难搞的是既要完整原始 Body 做审计，又要按不同协议解析（如同时支持 JSON 和 Protobuf），这时候复制才是合理选择 —— 但得加上大小限制和超时控制。
