c.saveuploadedfile不能用于多节点部署，因它仅将文件写入当前节点本地磁盘，节点间路径不共享，导致文件丢失或404；必须解耦上传与存储，统一接入minio/oss/s3等中心化对象存储，所有节点通过sdk上传并返回公共url。
c.SaveUploadedFile 不能直接用于多节点部署下的文件集中上传——它只把文件写到当前进程所在机器的本地磁盘，节点间不共享，会直接导致文件丢失或 404。
必须把“上传”和“存储”解耦，让所有节点统一将文件发往一个中心化存储服务。
为什么不能用 c.SaveUploadedFile 直接写本地
多节点时，用户上传请求可能落到任意一台机器，而 c.SaveUploadedFile 只保存在该节点的 ./uploads/ 或指定路径下。其他节点无法访问这个路径，前端后续请求图片或文件时就会 404；扩容缩容还会导致文件不可追溯。
必须替换为对象存储（如 MinIO / OSS / S3）
所有 Gin 节点共用同一套存储后端，上传逻辑变成：解析文件 → 读取内容 → 写入 MinIO bucket → 返回公共 URL。
-
c.FormFile或c.MultipartForm仍可用于获取文件元数据和流，但不再调用c.SaveUploadedFile - 用
minio.PutObject（或对应 SDK 的上传方法）替代本地写入 - 上传成功后返回的是可公开访问的 URL，不是本地路径
- MinIO 需独立部署（单机或集群），Gin 节点只负责转发和元数据处理
实际代码里要改哪几处
以 MinIO 为例，关键改动点：
- 去掉所有
c.SaveUploadedFile(file, dst)调用 - 用
file.Open()获取io.Reader，传给minioClient.PutObject - 生成唯一 key（建议含时间戳 + 随机字符串，避免覆盖）：
fmt.Sprintf("uploads/%s%s", uuid.New().String(), path.Ext(file.Filename)) - 设置
Content-Type：从file.Header.Get("Content-Type")或mime.TypeByExtension推断 - 上传失败必须显式返回错误，不能忽略
err—— 否则前端以为成功，实际文件没存进去
别漏掉 router.MaxMultipartMemory 和超时配置
默认 MaxMultipartMemory = 32 （32 MiB），大文件上传会触发内存溢出或 <code>http: request body too large 错误：
- 在
gin.Default()后立即设限：r.MaxMultipartMemory = 128 - 反向代理（如 Nginx）也要同步调大
client_max_body_size，否则请求根本到不了 Gin - MinIO 上传本身有超时，需用
context.WithTimeout包裹，防止 Goroutine 泄漏
