c.request.body 读一次变空是因为它是单次消费的 io.readcloser；需用 io.readall() 读取后通过 io.nopcloser(bytes.newbuffer(bodybytes)) 重置才能多次读取，且中间件中绝不能调用 c.shouldbindjson 等绑定方法。
为什么 c.Request.Body 读一次就变空？
因为 c.Request.Body 是一个 io.ReadCloser，底层是单次消费的流。调用 ioutil.ReadAll()、c.ShouldBindJSON() 或 c.GetRawData() 后，流指针已到 EOF，后续再读就是空字节或 io.EOF 错误。
如何安全地多次读取原始 Body？
必须在首次读取后，把内容重新包装成新的 io.ReadCloser 赋回 c.Request.Body。否则中间件和 handler 之间会互相“抢” Body，导致一方读不到数据。
-
c.GetRawData()是 Gin 提供的便捷方法，它内部已做了一次读取 + 重置，但只适用于**不修改 Body 的场景**（比如仅日志打印） - 若需在中间件中解析 JSON Schema、验签、审计后再交给 handler 绑定结构体，必须手动重置：
bodyBytes, err := io.ReadAll(c.Request.Body) if err != nil { c.AbortWithStatusJSON(400, gin.H{"error": "invalid body"}) return } c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes)) - 注意：不要用
strings.NewReader(string(bodyBytes))—— 中文或二进制内容可能因编码丢失；始终用bytes.NewBuffer()
中间件里读 Body 的典型陷阱
常见错误是直接在中间件里调用 c.ShouldBindJSON() 或 json.NewDecoder(c.Request.Body).Decode()，这会彻底耗尽 Body，后续 handler 再调 c.ShouldBindJSON() 就只能得到零值或 panic。
- 绑定类方法（
c.ShouldBindJSON、c.ShouldBindXML等）本质就是读 Body + 反序列化，不可逆 - 如果中间件需要校验但 handler 还要绑定，中间件只能用
c.GetRawData()或手动io.ReadAll()+ 重置，**绝不能调用任何 Bind 方法** - Content-Type 不匹配时，
c.GetRawData()仍能读出原始字节，但c.ShouldBindJSON()会直接报错，这点常被忽略
性能与边界情况提醒
重置 Body 的成本很低，但反复拷贝大 Body（如上传文件）会增加内存压力。生产环境要注意：
- Body 过大时（>1MB），建议加限长：用
http.MaxBytesReader包装原始c.Request.Body，避免 OOM - 某些代理或网关可能修改或 chunked 编码 Body，
c.GetRawData()在这类情况下可能失败，需 fallback 到手动io.LimitReader - Gin v1.9+ 的
c.Request.Body默认已支持io.Seeker（仅限内存 buffer 场景），但不要依赖——它不是标准行为，且不适用于所有部署环境
