gin 框架中，c.request.body 是一次性可读流，首次读取后即耗尽；若需在中间件校验后供后续处理器再次使用，必须手动“捕获并重置”请求体——即读取后将其内容写回一个可重复读的 io.readcloser。
gin 框架中，c.request.body 是一次性可读流，首次读取后即耗尽；若需在中间件校验后供后续处理器再次使用，必须手动“捕获并重置”请求体——即读取后将其内容写回一个可重复读的 io.readcloser。
在 Gin 中处理请求体（*http.Request.Body）时，一个常见误区是：直接调用 ioutil.ReadAll（或 io.ReadAll）后，Body 流即被消耗完毕，后续任何对 c.Request.Body 的读取都将返回空字节。这正是你示例中 /test 处理器输出空 body 的根本原因。
要实现「中间件读取并验证 Body，之后 Handler 仍能正常解析」，核心思路是：在中间件中完整读取 Body → 缓存其字节 → 将其封装为新的、可重复读的 io.ReadCloser → 替换原 c.Request.Body。
以下是符合 Go 1.19+ 最佳实践的完整解决方案（已弃用过时的 ioutil，改用 io 和 bytes）：
package main
import (
"bytes"
"fmt"
"io"
"net/http"
"github.com/gin-gonic/gin"
)
// captureAndResetBody 是一个通用中间件，用于捕获并重置请求体
func captureAndResetBody() gin.HandlerFunc {
return func(c *gin.Context) {
// 1. 读取原始 Body 全部内容
bodyBytes, err := io.ReadAll(c.Request.Body)
if err != nil {
c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "failed to read request body"})
return
}
_ = c.Request.Body.Close() // 显式关闭原始 Body（安全习惯）
// 2. 将字节切片封装为新的 io.ReadCloser
c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))
// 3. ✅ 此时可安全进行 JSON Schema 校验等操作
fmt.Printf("Validating body: %s\n", string(bodyBytes))
// 4. 继续执行后续中间件和路由处理器
c.Next()
}
}
type E struct {
Email string `json:"email"`
Password string `json:"password"`
}
func test(c *gin.Context) {
// 现在可以多次读取 Body（例如 Bind、ReadAll 等）
var data E
if err := c.ShouldBindJSON(&data); err != nil {
c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
return
}
fmt.Printf("Parsed data: %+v\n", data)
// 或者手动读取（验证 Body 是否仍可用）
bodyBytes, _ := io.ReadAll(c.Request.Body)
fmt.Printf("Body re-read: %s\n", string(bodyBytes))
c.JSON(http.StatusOK, gin.H{
"email": data.Email,
"password": "****", // 敏感信息脱敏
})
}
func main() {
router := gin.Default()
router.Use(captureAndResetBody()) // 关键：必须在其他依赖 Body 的中间件之前注册
router.POST("/test", test)
router.Run("127.0.0.1:8080")
}✅ 关键要点说明：
- 顺序至关重要：captureAndResetBody() 必须在所有依赖 c.Request.Body 的中间件（如 gin.Recovery() 之外的自定义校验）之前注册，否则可能被其他中间件提前消耗。
- io.NopCloser 的作用：它将 *bytes.Buffer（支持多次 Read）包装为满足 io.ReadCloser 接口的类型，完美替代原 Body。
- 内存安全提示：该方案将整个请求体加载至内存。对于大文件上传场景，应改用流式校验（如基于 json.Decoder 边读边校验），或结合 c.Request.MultipartForm 处理文件字段。
- 错误处理不可省略：实际项目中需严格检查 io.ReadAll 和 c.ShouldBindJSON 的错误，避免 panic 或静默失败。
- 性能权衡：虽然增加了内存拷贝，但这是 Gin 生态中保障 Body 可重用的标准且可靠模式，被 gin-contrib/sessions、gin-jwt 等主流扩展广泛采用。
通过此方法，你既能完成 JSON Schema 验证等前置逻辑，又能确保后续处理器（如 c.ShouldBindJSON 或自定义解析）获得完整、未损坏的请求数据——真正实现「一次捕获，多次复用」。
