gin通用日志中间件无法捕获大文件上传的完整请求体，因r.body只能读一次且默认不解析multipart；必须在parsemultipartform成功后、formfile调用前，从r.multipartform.file和value中提取文件名、大小等元数据并记录，同时defer removeall释放资源。
大文件上传日志不能靠通用日志中间件自动捕获完整请求体——r.Body 只能读一次，且默认不流式解析时根本拿不到文件名、大小等关键字段。日志里只记个 POST /upload 没意义，必须在 multipart 解析流程中插点取数。
为什么直接 log.Printf("%+v", r) 会漏掉文件信息
Go 的 http.Request 默认不解析表单，r.FormValue 和 r.MultipartForm 都为空；一旦调用 r.ParseMultipartForm，r.Body 就被消费完，后续再想读就 EOF。日志中间件若在 handler 执行前或后统一打日志，必然拿不到文件元数据。
- 没调
ParseMultipartForm：日志里只有空的r.MultipartForm == nil - 在中间件里提前调了
ParseMultipartForm(0)：body 被吞，真实 handler 里r.FormFile失败 - 用
io.TeeReader复制 body 写日志：大文件直接 OOM，和io.ReadAll一样危险
必须在 ParseMultipartForm 后、FormFile 前取日志字段
真正可用的上传上下文，只存在于 r.ParseMultipartForm 成功返回之后、且 r.MultipartForm 还未被清理之前。这时才能安全访问 r.MultipartForm.Value（普通字段）和 r.MultipartForm.File（文件列表）。
- 文件名从
file.Header.Filename拿，不是r.FormValue("filename")——后者可能为空或错位 - 文件大小要靠
file.Size，不是r.ContentLength——multipart 请求里这个值常为 -1 - 必须
defer r.MultipartForm.RemoveAll()，否则临时文件和内存不释放，日志中间件不能替代这步 - 如果用了分片上传，
X-Upload-ID、X-Part-Number这类 header 要在ParseMultipartForm前就读，比如r.Header.Get("X-Upload-ID")
怎么避免日志中间件干扰流式处理
日志本身不该触发任何 Body 读取或 ParseMultipartForm 调用。正确姿势是把日志逻辑下沉到业务 handler 内部，在已确认解析成功、拿到文件句柄之后再记录。
- 不要在 Gin/Zap 中间件里调
c.Request.ParseMultipartForm——破坏 handler 控制流 - 别用
c.ShouldBind绑定 multipart 表单，它内部会强制解析，且无法控制maxMemory - 推荐结构：
r.ParseMultipartForm(32 → <code>file, header, _ := r.FormFile("file")→log.Info("upload", "name", header.Filename, "size", header.Size) - 如果必须复用中间件，让它只记录 method、path、status、latency，文件相关字段留到 handler 里填，通过
context.WithValue透传
最易被忽略的一点：日志里记了 header.Size，但这个值来自 multipart header 的 Content-Length 字段，前端可伪造。真要防恶意，得在流式写入目标路径时用 io.TeeReader + hash.Hash 实时校验，日志字段只是辅助，不能当真相。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
