Gin 中 c.Request.Body 默认只能读一次，是 HTTP 流式设计的必然结果；安全复用需在中间件中用 io.ReadAll 读取、Close 原 Body、再以 io.NopCloser(bytes.NewReader(buf)) 重置，且须控制大小防 OOM。
直接说结论：Gin 中 c.Request.Body 默认只能读一次，不是 bug，是 HTTP 流式设计的必然结果；想安全复用，必须手动缓存并重置，但“怎么缓存”“缓存到哪”“什么时候重置”，才是高阶方案的关键分水岭。
为什么 c.ShouldBindBodyWith 不是万能解药
很多人看到文档里推荐 c.ShouldBindBodyWith 就以为万事大吉——它确实能对同一个 Body 多次调用（比如先校验再绑定），但前提是：所有消费都必须走它，且不能混用 c.BindJSON、io.ReadAll 或 json.NewDecoder 等底层读取方式。
常见踩坑点：
-
c.ShouldBindBodyWith内部只缓存一次 Body 字节，后续每次调用都从内存 copy 一份新 reader；但如果中间件里先用了io.ReadAll(c.Request.Body)，原始 Body 已耗尽，ShouldBindBodyWith就会读不到东西，直接报EOF - 它不兼容自定义解析逻辑（比如你得先提取某个 header + body 拼接做签名验证），因为缓存时机在 Bind 前，无法介入原始流
- 如果下游 handler 用的是
c.GetRawData()，这个方法内部仍会尝试读原始c.Request.Body，此时已被消耗，返回空 slice
中间件中手动捕获 Body 的正确姿势
真正可控、可扩展的方案，是在中间件里主动读取、缓存、重置。关键不是“能不能做”，而是“怎么做才不翻车”。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须用
io.ReadAll(c.Request.Body)（Go 1.16+，别用已弃用的ioutil.ReadAll） - 读完后立刻调用
c.Request.Body.Close()，否则连接可能泄漏（尤其在长连接或代理环境下） - 缓存字节后，用
bytes.NewReader(buf)构造 reader，再套一层io.NopCloser赋值回c.Request.Body，确保类型匹配 - 如果请求体可能很大（比如上传文件、批量导入），加长度限制，避免 OOM：
http.MaxBytesReader包一层再传给io.ReadAll
示例片段：
buf, err := io.ReadAll(http.MaxBytesReader(c.Writer, c.Request.Body, 2<<20)) // 限制 2MB
if err != nil {
c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "body too large"})
return
}
c.Request.Body.Close()
c.Request.Body = io.NopCloser(bytes.NewReader(buf))
多个中间件串联时 Body 复用的陷阱
当 Body 需被多个中间件读取（比如鉴权中间件校验签名 + 日志中间件记录原始请求 + 业务中间件 Schema 校验），顺序和重置时机就极其关键。
核心原则：Body 只能被「第一个」中间件完整读取并重置；后续中间件必须基于重置后的 c.Request.Body 操作，不能再碰原始流。
容易出错的情况：
- 两个中间件都各自调用
io.ReadAll(c.Request.Body)—— 第二个一定读到空，因为第一个已把它耗尽 - 日志中间件在鉴权中间件之前执行，但没重置 Body，导致鉴权失败
- 用
c.GetRawData()的中间件和用c.ShouldBindBodyWith的 handler 混用，前者会把缓存清空，后者再调就失效
推荐做法：把 Body 捕获逻辑收敛到一个前置中间件（如 recoverBody），并确保它注册在所有依赖 Body 的中间件之前；其他中间件统一使用重置后的 c.Request.Body 或直接从上下文 c.Set("raw_body", buf) 取缓存。
真正麻烦的从来不是“怎么让 Body 可读两次”，而是当服务跑在线上、流量进来、各种中间件堆叠、不同团队写的模块混在一起时，谁动了 Body、谁关了它、谁又悄悄替换了它——这些细节一旦漏掉，问题就藏在日志背后，等你花半天才发现是 c.Request.Body 被提前 Close 了。
