c.GetRawData()是最安全直接的方式，它自动重置Body流，避免手动处理io.ReadCloser生命周期和破坏后续绑定；而直接读取c.Request.Body会导致仅能读一次且无法绑定。
c.GetRawData() 是最安全、最直接的方式，不用手动处理 io.ReadCloser 生命周期，也不会破坏后续绑定逻辑。
为什么不能直接打印 c.Request.Body
因为 c.Request.Body 是一个 io.ReadCloser 接口，不是字符串。用 fmt.Printf("%s", c.Request.Body) 只会输出类似 &{0xc00012a000} 的地址信息，不是实际内容。更关键的是：它只能被读一次——一旦被消耗（比如调用过 io.ReadAll()），后续所有读取都返回空。
c.GetRawData() 与手动读取 Body 的区别
c.GetRawData() 内部已做了重置处理，它会完整读取原始字节，并自动把 Body 恢复为可再次使用的状态（即等效于手动执行了 c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))）。而手动读取容易漏掉这步，导致 c.ShouldBindJSON() 失败。
- ✅ 推荐：
c.GetRawData()—— 简洁、安全、不干扰 Gin 绑定流程 - ⚠️ 风险操作：
io.ReadAll(c.Request.Body)后未重置c.Request.Body—— 后续c.ShouldBindJSON()或c.PostForm()全部失效 - ⚠️ 注意：
c.GetRawData()仍会消耗 Body 流；若需多次读取（如中间件校验 + handler 绑定），必须在中间件里缓存并重置
什么时候该用 c.GetRawData()
适用于以下真实场景：
- 调试第三方推送（如微信、支付宝回调），需要确认原始 JSON 是否含非法字符或格式异常
- 做 JSON Schema 校验前，先拿到完整字节流进行预检
- 日志记录原始请求体（注意脱敏，避免泄露敏感字段）
- Content-Type 不是标准
application/json，但你仍想按 JSON 解析（比如某些旧系统发text/plain包 JSON）
示例：
raw, err := c.GetRawData()
if err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "invalid body"})
return
}
fmt.Printf("Raw: %s\n", string(raw))
// 此时仍可正常绑定
var payload struct {
Event string `json:"event"`
}
if err := c.ShouldBindJSON(&payload); err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": err.Error()})
return
}
容易被忽略的细节
即使用了 c.GetRawData()，也要注意两点：
- 它返回的是
[]byte，不是string；如果要 JSON.Compact 或正则匹配，先转string(raw)或直接操作字节 - Body 超过内存限制（默认无限制，但生产环境应设限）时，
c.GetRawData()可能 panic 或 OOM；建议配合c.Request.ContentLength做前置判断，或用中间件统一加maxMemory限制 - 如果请求是
multipart/form-data（带文件），c.GetRawData()会读出整个混合 boundary 数据，此时不该用它——应改用c.FormFile()或c.MultipartForm()
