容器内上传文件会丢失，是因为c.SaveUploadedFile默认写入容器可写层，该层随容器销毁而清除；必须挂载Volume（如-v /data/uploads:/app/uploads）或改用云存储，使文件落至宿主机或外部持久化存储。
上传文件在容器里一删就丢，必须把文件落到宿主机或外部存储，不能依赖容器内部路径。
为什么 c.SaveUploadedFile 默认保存在容器内会丢失
调用 c.SaveUploadedFile(file, "./uploads/"+file.Filename) 时，文件实际写入的是容器的可读写层（container r/w layer）。这个层属于非持久化数据——容器停止、重启或删除后，所有内容清空。即使你手动 docker commit 生成新镜像，也不解决运行时动态上传场景，且违反“不可变基础设施”原则。
- 常见错误现象：本地测试一切正常，上线 Docker 部署后，上传成功但重启容器就找不到文件
- 根本原因：路径
"./uploads/"是相对容器根目录的路径，Docker 不管理它，也不备份它 - 正确思路：让
SaveUploadedFile的dst参数指向一个**宿主机挂载进来的持久化位置**，而不是容器内部任意路径
用 Volume 挂载宿主机目录到容器内上传路径
这是最简单可控的方式，适合开发、测试及中小规模部署。关键是在运行容器时，把宿主机一个真实存在的目录（如 /data/uploads）挂载到容器内你代码中写的保存路径（如 /app/uploads）。
- 先确保宿主机目录存在并有写权限：
mkdir -p /data/uploads && chmod 755 /data/uploads - 启动容器时挂载：
docker run -v /data/uploads:/app/uploads your-gin-app - Gin 代码中保持原逻辑，但路径需与挂载目标一致：
c.SaveUploadedFile(file, "/app/uploads/"+file.Filename) - 验证方式：上传后直接在宿主机执行
ls /data/uploads，文件应立刻可见
改用云存储（如阿里云 OSS）绕过本地持久化问题
当业务需要高可用、多实例共享、防盗链或 CDN 加速时，硬靠挂载目录反而带来运维负担。此时应跳过本地保存环节，直接上传到对象存储。
- 不调用
c.SaveUploadedFile，而是用c.FormFile获取*multipart.FileHeader后，打开流并直传 OSS/COS/Qiniu - 示例关键步骤：
file, _ := c.FormFile("file")→src, _ := file.Open()→ossClient.PutObject(..., src) - 优势：上传路径与容器解耦；天然支持横向扩容；删除容器不影响已有文件；可配合签名 URL 实现临时访问控制
- 注意点：务必设置超时和重试；上传失败要清理已打开的
src（用defer src.Close()）；敏感环境密钥不要硬编码，走环境变量或 Secret
别踩的坑：Bind Mount 权限与路径一致性
用 -v 挂载时，最容易忽略两个细节，导致 SaveUploadedFile 报 permission denied 或静默失败：
- 容器内进程用户（如默认的
root或你指定的非 root 用户）必须对挂载目标目录有写权限。Alpine 镜像常以非 root 运行，需提前chown -R 1001:1001 /data/uploads并在 Dockerfile 中USER 1001 -
dst字符串必须严格匹配挂载路径。比如挂载的是-v /data/uploads:/app/uploads，就不能写成"./uploads/xxx"或"/app/uploads//xxx"（双斜杠可能触发不同行为） - Windows/macOS 使用 Docker Desktop 时，
/data/uploads要换成 WSL2 或 Hyper-V 共享路径（如/c/Users/xxx/uploads），否则挂载无效
真正麻烦的从来不是怎么写上传逻辑，而是上传之后文件“还在不在”。只要路径没落到宿主机或云存储上，就等于没存。
