Gin上传文件需动态生成日期子目录：先用time.Now().Format("2006/01/02")获取安全路径格式，再通过filepath.Join拼接uploadDir，调用os.MkdirAll确保目录存在后，方可使用c.SaveUploadedFile保存。
上传文件时如何动态生成日期子目录
Gin 本身不处理文件存储路径逻辑，得在 c.FormFile 拿到文件后、调用 file.Open 或 c.SaveUploadedFile 前，自己拼出带日期的路径。关键不是“怎么存”，而是“路径不能硬编码”——得从当前时间提取年/月/日，再组合成类似 uploads/2024/06/15/xxx.jpg 的结构。
常见错误是直接用 time.Now().Format("2006-01-02") 得到字符串后乱拼路径，结果在 Windows 上出现反斜杠、Linux 上权限失败，或遇到日期格式含非法字符（比如冒号）导致 os.MkdirAll 报错 invalid argument。
- 用
time.Now().Format("2006/01/02")，斜杠天然适配所有系统路径分隔符 - 路径拼接统一用
filepath.Join，别用字符串 + - 必须提前创建目录：先
os.MkdirAll(uploadDir, 0755)，否则SaveUploadedFile会因父目录不存在而失败 - 注意时区：如果业务要求按用户所在地日期分类，别直接用
time.Now()，改用time.Now().In(loc)（loc从time.LoadLocation("Asia/Shanghai")获取）
使用 c.SaveUploadedFile 时怎么传入动态路径
c.SaveUploadedFile 第二个参数是目标文件路径（string），它不支持目录自动创建，所以不能直接传 filepath.Join("uploads", "2024/06/15", filename) 就完事。必须拆成两步：先确保目录存在，再保存。
示例代码片段：
file, err := c.FormFile("file")
if err != nil {
c.JSON(400, gin.H{"error": err.Error()})
return
}
datePath := time.Now().Format("2006/01/02")
uploadDir := filepath.Join("uploads", datePath)
if err := os.MkdirAll(uploadDir, 0755); err != nil {
c.JSON(500, gin.H{"error": "failed to create upload dir"})
return
}
dst := filepath.Join(uploadDir, file.Filename)
if err := c.SaveUploadedFile(file, dst); err != nil {
c.JSON(500, gin.H{"error": err.Error()})
return
}
注意：file.Filename 是客户端传来的原始文件名，可能含路径（如 ../../etc/passwd），生产环境务必清洗——用 filepath.Base(file.Filename) 取纯文件名，否则有路径遍历风险。
为什么不用 os.Create + io.Copy 而用 SaveUploadedFile
c.SaveUploadedFile 底层其实也是打开临时文件再 copy，但它做了几件关键事：校验文件是否已读完、清理 multipart 临时缓冲、避免重复读取 body。如果手动用 os.Create，容易漏掉 file.Open() 后的 defer f.Close()，或者在 copy 失败时没删临时文件，导致磁盘被占满。
- 除非你需要边上传边处理（比如实时压缩、加水印），否则优先用
SaveUploadedFile - 如果真要用
io.Copy，记得从file.Open()得到的src读，而不是从c.Request.Body—— 后者已被 Gin 解析 multipart 时消费过了 -
SaveUploadedFile对大文件更友好，它内部用了 buffer 分块写入，不会把整个文件 load 进内存
并发上传时日期目录会不会冲突或重复创建
os.MkdirAll 是线程安全的：即使多个 goroutine 同时执行，它只会成功创建一次，其余调用返回 nil。所以不用加锁或检查目录是否存在——直接调用即可。
但要注意两个边界情况：
- 如果服务器时间回拨（比如 NTP 校时），同一秒内可能生成两个不同日期路径（如从 2024/06/15 11:59:59 回拨到 2024/06/15 11:59:58），这属于系统时间问题，应用层无法规避，只能接受
- 如果上传量极大（每秒数千），
os.MkdirAll频繁调用会有轻微开销，但实测在 SSD 上单次耗时
真正该关注的是磁盘空间监控和过期文件清理——按日期分类只是方便归档，不代表系统会自动删旧目录。
