直接读取 c.Request.Body 后下游拿不到数据，因其是单次读取的 io.ReadCloser，读完即 EOF；应优先用 c.ShouldBindBodyWith 缓存并复用 body，需重写时才手动捕获、修改字节并替换 Body 及更新 ContentLength。
为什么直接读取 c.Request.Body 后下游就拿不到数据
因为 http.Request.Body 是一个一次性 io.ReadCloser，底层可能是网络连接缓冲区或 bytes.Reader。调用 io.ReadAll(c.Request.Body) 或 c.BindJSON() 之后，读指针已到 EOF，后续再读就是空字节或 io.EOF 错误——这不是 Gin 的 bug，是 Go HTTP 标准库的设计约束。
用 c.ShouldBindBodyWith 替代手动读取（最简方案）
如果只是想在中间件里校验一次 body、又让 handler 能正常绑定，别碰 Body 流本身，直接用 Gin 内置的 c.ShouldBindBodyWith：
- 它内部会把 body 读一次、缓存字节、再分别供校验和后续绑定使用
- 无需手动替换
c.Request.Body，无内存拷贝风险，兼容所有 binding 类型（binding.JSON、binding.XML等） - 只适用于「校验 + 绑定」场景，不适用于需修改 body 内容的重写需求
示例：c.ShouldBindBodyWith(&req, binding.JSON) —— 这行执行完，req 已填充，且后续 c.BindJSON(&v) 仍能成功。
需要真正重写 body 时：捕获 → 修改 → 替换 c.Request.Body
比如脱敏手机号、注入 trace ID、或统一添加字段。必须自己接管流：
立即学习“go语言免费学习笔记（深入）”；
- 先用
io.ReadAll(c.Request.Body)读出原始字节 - 对字节切片做修改（如
bytes.ReplaceAll、json.Unmarshal后改字段再json.Marshal） - 用
bytes.NewReader(modifiedData)创建新 reader，再套一层io.NopCloser构造io.ReadCloser - 赋值回
c.Request.Body = io.NopCloser(bytes.NewReader(modifiedData)) - 注意：修改后要同步更新
c.Request.ContentLength，否则某些客户端或代理可能出错
关键点：io.NopCloser 不会自动关闭底层 reader，所以用 bytes.NewReader 是安全的；别用 strings.NewReader，它不支持 Seek，部分 binding 库（如 xml.Decoder）可能失败。
拦截特定请求的路由匹配与 Body 重写时机
Body 必须在任何绑定或解析前重写，否则原始流已被消耗。所以中间件注册位置很关键：
- 全局注册：
router.Use(rewriteMiddleware)，但需在gin.Logger()和gin.Recovery()之后、其他业务中间件之前 - 局部注册：只对某组路由生效，比如
v1 := router.Group("/api/v1"); v1.Use(rewriteMiddleware) - 判断条件建议用
c.Request.URL.Path和c.Request.Method，避免依赖 query 或 header（它们可能还没被解析） - 若需基于 body 内容判断是否重写，必须先完整读取一次——这意味着所有请求都会经历一次内存拷贝，高并发下要注意 GC 压力
真正容易被忽略的是 Content-Length 和 Transfer-Encoding 头的同步更新。Body 字节变了但头没改，下游服务或反向代理可能截断或拒绝请求。
