根本原因是http.Request.Body是单次消耗的io.ReadCloser，日志中间件读取后指针移至末尾，导致后续Handler读取为空；需重建可重读的ReadCloser，而非简单复制，并用http.MaxBytesReader限制读取长度。
日志中间件里读一次Body后业务Handler拿不到数据
根本原因是 http.Request.Body 是 io.ReadCloser，底层是单次消耗的流。日志中间件调用 io.ReadAll(r.Body) 后，指针已移到末尾，后续 json.NewDecoder(r.Body).Decode() 只会读到 EOF 或空字节。
必须在读完后把原始数据“还回去”，且要保证 r.Body 仍满足 io.ReadCloser 接口。关键不是“复制”，而是“重建可重读的 ReadCloser”。
- 先用
http.MaxBytesReader包一层，限制最大读取长度（如1 ），防 OOM - 调用
io.ReadAll(r.Body)获取完整[]byte - 显式调用
r.Body.Close()（否则连接资源可能泄漏） - 用
bytes.NewReader(data)创建新 reader，再套io.NopCloser()补上Close()方法 - 赋值回
r.Body = io.NopCloser(bytes.NewReader(data))
ContentLength 和 Header 不同步会导致 Gin binding 失败
Gin 的 c.ShouldBindJSON() 依赖 r.ContentLength 和 r.Header.Get("Content-Length") 一致。如果只重置 r.Body 却没更新这两项，binding 会跳过 body 解析或 panic。
实操中容易漏掉这步，尤其当原始请求带 Transfer-Encoding: chunked 时，r.ContentLength 原本就是 -1，但重置后若不显式设回，某些 handler 会误判为空 body。
- 读取前记下原始
r.ContentLength（若为 -1，说明是 chunked，后续不设 Content-Length） - 读取完成后，若原始
ContentLength > 0，执行r.ContentLength = int64(len(data)) - 同时更新 header：
r.Header.Set("Content-Length", strconv.FormatInt(r.ContentLength, 10)) - 对
application/x-www-form-urlencoded或multipart/form-data，优先走r.ParseForm()，别硬读r.Body
GET 请求不该读 Body，但有些客户端会塞数据
HTTP 规范没禁止 GET 带 body，但绝大多数服务端框架（包括 net/http 默认行为）不处理它。强行 io.ReadAll(r.Body) 在 GET 场景下可能阻塞、超时，或读到意外空数据。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
是否读 body 应由方法和实际需求决定，不能无条件统一处理。
- 开头加判断：
if r.Method == "GET" || r.Method == "HEAD" { next.ServeHTTP(w, r); return } - 若业务明确需要支持 GET + body（如某些内部 RPC），再启用读取逻辑
- 避免在中间件里对所有方法都调
r.ParseForm()，它内部也会尝试读 body，重复触发问题
用 SHA256 摘要代替明文日志更安全也更省内存
全量缓存 []byte 有内存压力，尤其高并发小 body 场景；而直接记录原始 JSON 易泄露敏感字段（如 token、密码）。摘要方式兼顾审计与脱敏。
注意：摘要必须基于原始未 decode 的字节流，否则不同客户端 URL 编码差异会导致哈希不一致，失去唯一性校验意义。
- 计算摘要前，确保用的是
io.ReadAll读出的原始[]byte，不是r.FormValue或r.PostForm解析后的字符串 - 对
application/json，直接哈希原始字节；对application/x-www-form-urlencoded，哈希r.URL.RawQuery + r.Body（需先r.ParseForm()确保 body 已解析） - 摘要值建议存进结构化日志字段，如
slog.String("body_sha256", fmt.Sprintf("%x", sum))
最易被忽略的是 r.Body.Close() 调用时机 —— 必须在 io.ReadAll 完成后、重建 r.Body 前立刻执行，晚一步就可能让底层 socket 缓冲区滞留，引发连接复用异常或内存缓慢增长。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
