gin 中 c.request.body 只能读一次，因其底层是 io.readcloser，指向一次性网络流，读取后缓冲区耗尽即返回 eof；解决方法是在中间件中用 io.readall 缓存字节，再以 bytes.newreader 和 io.nopcloser 重建可重放 body。
为什么ctx.Request.Body只能读一次
Gin 基于 net/http，而 Go 标准库的 http.Request.Body 是一个 io.ReadCloser，底层通常指向一次性的网络连接流。一旦调用 io.ReadAll 或 json.NewDecoder 读取过，内部 buffer 就被耗尽，后续再读就返回空或 io.EOF。Gin 的 c.ShouldBindJSON()、c.PostForm() 等方法内部都会消费 Body，所以不能多次直接读。
如何让 Body 可重复读取（推荐方案）
最稳妥的方式是提前把 Body 缓存到内存，并替换为可重放的 io.ReadCloser。Gin 官方不自动做这事，需手动干预：
- 在中间件中尽早调用
io.ReadAll(c.Request.Body)，保存原始字节 - 用
bytes.NewReader()和io.NopCloser()构造新的Body - 必须在任何绑定逻辑（如
ShouldBindJSON）之前完成，否则已消费
示例中间件：
func CacheRequestBody() gin.HandlerFunc {
return func(c *gin.Context) {
body, err := io.ReadAll(c.Request.Body)
if err != nil {
c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "read body failed"})
return
}
c.Set("raw_body", body) // 可选：供后续 handler 获取原始数据
c.Request.Body = io.NopCloser(bytes.NewReader(body))
c.Next()
}
}
然后注册：router.Use(CacheRequestBody())
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
c.ShouldBindJSON() 和手动读取冲突怎么办
如果既想用 ShouldBindJSON 解析结构体，又想保留原始 JSON 字符串（比如记录日志、转发），就不能在绑定后再去读 Body —— 此时它已为空。正确顺序是：
- 先缓存 Body（如上中间件）
- 再调用
c.ShouldBindJSON(&v)—— 它会从新构造的可重放 Body 读取 - 需要原始内容时，从
c.Get("raw_body")取出[]byte，转成string或重新解析
注意：ShouldBindJSON 内部会重置 Body 位置（因为用了 bytes.NewReader），所以它和你的缓存不冲突；但如果你自己用 json.Decoder 且没重置，就会出问题。
大 Body 场景下的内存与性能风险
缓存整个 Body 到内存对小请求没问题，但上传文件或超长 JSON 时可能 OOM。这时候要权衡：
- 仅对特定路由启用缓存（比如只对
/api/webhook） - 加长度限制：
if len(body) > 1024*1024 { ... return } // 1MB 上限 - 避免在中间件里无条件缓存所有请求
- 若需透传大 Body（如代理），改用
io.Copy直接转发，不落地
另外，io.NopCloser(bytes.NewReader(body)) 不支持 Seek，所以别指望用 body.Seek(0,0) 回滚 —— 它只是个一次性 reader，靠的是你提前存好的副本。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
