直接在文件上传 handler 里加耗时统计和日志逻辑更可控准确，因为 gin.Logger() 不记录文件名、大小、保存路径及 multipart 解析与磁盘写入耗时，无法定位上传瓶颈，且错误日志缺乏上下文。
直接在文件上传 handler 里加耗时统计和日志逻辑，比塞进通用中间件更可控、更准确
为什么不能只靠 gin.Logger() 记录上传行为
gin.Logger() 默认不记录请求体、文件名、大小、保存路径等关键信息，对上传类请求几乎没用；它也不感知 c.FormFile() 和 c.SaveUploadedFile() 的执行耗时，只统计到 handler 入口和返回之间的时间 —— 而真正耗时的大头（解析 multipart、磁盘写入）被它漏掉了。
常见错误是以为启用了 gin.Logger() 就万事大吉，结果线上上传慢得离谱却查不到瓶颈点。
- 它不会打印
file.Filename、file.Size - 无法区分是网络接收慢、解析慢，还是磁盘写入慢
- 如果上传失败（比如
c.FormFile()报错），gin.Logger() 仍会记一条“200”或“400”，但没上下文
怎么在 upload handler 里手动加耗时和日志
核心原则：把 time.Now() 放在 c.FormFile() 前，把关键指标（文件名、大小、保存路径、错误）全打进去，避免事后补查。
示例代码片段：
router.POST("/upload", func(c *gin.Context) {
start := time.Now()
file, err := c.FormFile("file") // ← 耗时起点从这里开始
if err != nil {
log.Printf("[UPLOAD FAIL] %s | %s | error: %v | cost: %v",
c.ClientIP(), c.Request.URL.Path, err, time.Since(start))
c.JSON(http.StatusBadRequest, gin.H{"error": "no file received"})
return
}
savePath := "./uploads/" + file.Filename
saveStart := time.Now()
if err := c.SaveUploadedFile(file, savePath); err != nil {
log.Printf("[UPLOAD SAVE FAIL] %s | %s | %s | size: %d | cost: %v | save_cost: %v",
c.ClientIP(), c.Request.URL.Path, file.Filename, file.Size,
time.Since(start), time.Since(saveStart))
c.JSON(http.StatusInternalServerError, gin.H{"error": "save failed"})
return
}
log.Printf("[UPLOAD OK] %s | %s | %s | size: %d | cost: %v | save_cost: %v",
c.ClientIP(), c.Request.URL.Path, file.Filename, file.Size,
time.Since(start), time.Since(saveStart))
c.JSON(http.StatusOK, gin.H{"filename": file.Filename, "size": file.Size})
})
-
c.FormFile()可能因 multipart 解析失败而卡住，必须单独测它的耗时 -
c.SaveUploadedFile()是同步 I/O，真实磁盘性能直接影响上传体验，必须单独埋点 - 日志里带上
file.Size，方便后续做上传大小分布分析 - 不要用
defer包裹整个 handler 日志 —— 错误分支提前 return 会导致 defer 不执行
怎么避免日志刷爆磁盘或拖慢上传
高并发上传场景下，每条日志都写磁盘会成为瓶颈。重点不是“要不要记”，而是“记什么”和“怎么记”。
- 成功日志建议采样，比如只记录 1% 的上传（用
hash/fnv对c.ClientIP()+c.Request.URL.Path哈希后取模） - 失败日志必须 100% 记录，且带完整 error stack（可用
fmt.Sprintf("%+v", err)） - 避免在 handler 里做格式化字符串拼接后再传给
log.Printf—— 改用log.Printf(format, args...)延迟格式化 - 如果用
zap等结构化日志库，确保开启EncoderConfig.EncodeLevel = zapcore.CapitalLevelEncoder等基础优化
额外要注意的坑
文件上传涉及 HTTP 协议层、Gin 解析层、OS 文件系统层三重交互，几个容易忽略的点：
-
c.FormFile()失败可能是因为请求 header 缺Content-Type: multipart/form-data，但 gin.Logger() 不会告诉你缺啥 - 前端用
fetch上传时忘了加FormData.append("file", input.files[0])，后端收不到 file 字段，c.FormFile("file")直接返回 error -
c.SaveUploadedFile()写入路径不存在会 panic，务必提前os.MkdirAll("./uploads", 0755) - 如果启用了
gzip中间件，确保它放在 upload handler 之前 —— 否则压缩会干扰 multipart boundary 解析
最麻烦的其实是“上传成功但文件内容损坏”，这通常发生在客户端未正确设置 boundary 或服务端内存限制过低（router.MaxMultipartMemory 默认 32 MiB），这类问题单靠耗时日志发现不了，得靠校验文件 hash 或抽样读取内容头。
