gin不控制上传路径，c.saveuploadedfile()的dst参数需显式指定完整路径；直接拼接file.filename存在目录穿越、覆盖、非法字符等严重安全风险，必须经securejoin和sanitizefilename双重校验。
直接说结论： Gin 本身不生成或控制上传文件的“路径”，c.SaveUploadedFile() 的 dst 参数就是你**必须显式指定的完整目标路径（含文件名）**，路径安全性、目录存在性、权限和命名逻辑全由你负责。
为什么不能直接拼接 file.Filename 作路径
用户上传的 file.Filename 是客户端可控的，可能包含：../etc/passwd、shell.php、空字节、Unicode 路径遍历字符等。直接拼进 dst 会导致：
– 目录穿越（写入任意系统路径）
– 文件覆盖（同名覆盖关键配置）
– 文件系统拒绝（非法字符导致 os.Create 失败）
– 安全审计失败
安全构造 dst 的实操要点
用 securejoin.SecureJoin() 替代字符串拼接，它会主动剥离危险路径段：
import "github.com/cpuguy83/securejoin"
// ✅ 正确：强制限定在 uploads/ 下
dst := securejoin.SecureJoin("uploads", sanitizeFilename(file.Filename))
if dst == "" {
c.JSON(400, gin.H{"error": "invalid filename"})
return
}
-
sanitizeFilename()需自行实现：移除/、、..、控制字符，保留字母数字和常见分隔符（如-_.） - 不要信任
filepath.Clean()—— 它不防御空字节或 Unicode 归一化绕过 - 确保
uploads/目录存在且进程有写权限；os.MkdirAll("uploads", 0750)应在启动时执行，而非每次请求
c.SaveUploadedFile() 的路径行为细节
该方法内部调用 os.Create(dst)，所以：
– dst 必须是**绝对路径**或**相对于当前工作目录的相对路径**（Gin 启动位置决定）
– 不会自动创建父目录；若 uploads/2026/09/ 不存在，保存会失败
– 若 dst 已存在，会直接覆盖（无提示）
- 生产环境建议用带时间戳或哈希前缀的文件名，例如：
fmt.Sprintf("uploads/%s_%d%s", hash, time.Now().Unix(), ext) - 避免使用用户原始扩展名做 MIME 判断；应通过
file.Header的前几百字节做 magic number 检查 - Windows 下注意路径分隔符一致性；
filepath.Join()比手动拼"\"更可靠
多文件上传时路径处理的额外坑
用 c.MultipartForm() 获取多个 file 后，每个都需单独走一遍安全路径构造流程：
form, _ := c.MultipartForm()
for _, fh := range form.File["files"] {
safeName := sanitizeFilename(fh.Filename)
dst := securejoin.SecureJoin("uploads", safeName)
// ⚠️ 这里必须检查 dst 是否为空，否则 SaveUploadedFile 会 panic
if err := c.SaveUploadedFile(fh, dst); err != nil {
// ...
}
}
- 前端
<input type="file" name="files" multiple>在不同浏览器中可能生成files[]或files字段名，务必与后端 key 一致 - 并发保存多个文件时，
dst冲突（同名）会导致后写覆盖前写；加随机前缀或 UUID 是简单解法 - 大文件场景下，
c.MaxMultipartMemory默认 32 MiB，超限会报http: request body too large，需提前设大
路径不是“填个字符串就完事”的环节，它是文件上传链路里最易被忽略、但一旦出错后果最重的一环——越简单的业务逻辑，越要警惕客户端传来的那个 Filename 字段。
