c.FormFile 正确获取文件句柄需确保字段名一致，返回 *multipart.FileHeader 后必须调用 Open() 获取 io.Reader，不可直接读 c.Request.Body 或传 header 本身；需校验 header.Size 防空文件，并用其 Size 和 Header 中 ContentType 传给 MinIO PutObject。
上传文件时怎么用 c.FormFile 正确获取文件句柄
别直接读 c.Request.Body，Gin 的 multipart 解析必须走 c.FormFile，否则会丢失边界、解析失败或报 http: no such file。它返回的是 *multipart.FileHeader，含文件名、大小、Header 等元信息，且已校验过 MIME 类型和字段存在性。
常见错误是传错字段名（比如前端用 file，后端却写 c.FormFile("files")），导致返回 nil, err；或者没调用 Open() 就直接传给 MinIO，结果传进去的是空流。
- 确保前端
<input type="file" name="file">的name和后端c.FormFile("file")一致 - 必须对返回的
*multipart.FileHeader调用Open()得到io.Reader，不能直接传header - 检查
header.Size是否为 0，避免空文件上传成功但内容为空
MinIO 客户端怎么用 PutObject 存原始文件流
PutObject 是最直接的方式，它接受 io.Reader，不强制要求提前知道长度——这对上传接口很关键，因为浏览器上传的流长度可能不准（尤其 chunked 编码下）。但要注意：MinIO 默认启用服务端校验（x-amz-checksum-sha256），若传入的 reader 不支持 Seek()（如 multipart.FileHeader.Open() 返回的 reader），会自动降级为 MD5 校验，不影响存储，但日志里可能出现警告。
- 桶名必须已存在，
PutObject不会自动创建桶，否则报BucketNotFound - 对象 key 建议拼上时间戳或 UUID 避免覆盖，例如
fmt.Sprintf("uploads/%s_%s", uuid.New(), header.Filename) - 显式传
header.Size作为objectSize参数，能让 MinIO 更早判断空间是否足够，避免上传一半失败 - Content-Type 推荐从
header.Header.Get("Content-Type")取，而不是硬编码"application/octet-stream"
为什么不能跳过内存拷贝直接用 c.Request.Body 推给 MinIO
Gin 在调用 c.FormFile 时已把整个 multipart body 解析进内存或临时磁盘（取决于 MaxMultipartMemory 配置），之后 c.Request.Body 已被消费完。再读会得到空流或 http: invalid Read on closed Body 错误。
- 默认
MaxMultipartMemory = 32 （32MB），超限会自动写临时文件，但 <code>c.Request.Body仍不可重复读 - 不要试图用
io.TeeReader或io.MultiReader“复用” body，multipart 边界解析只做一次 - 如果真要绕过
FormFile（比如处理超大文件流式上传），得用c.Request.MultipartReader()自己解析，但复杂度陡增，一般没必要
上传完成后怎么安全地清理临时文件（如果用了 SaveUploadedFile）
有些示例会先调 c.SaveUploadedFile 把文件落地到本地磁盘再读取上传，这多了一次 I/O，还容易漏删临时文件导致磁盘占满。除非你要做病毒扫描、格式校验等必须落盘的操作，否则应直接用 header.Open() 流式上传。
- 如果用了
SaveUploadedFile，务必在defer os.Remove()或上传成功后立即删除，别等函数结束——出错时可能没机会执行 - 注意 Windows 下文件正被打开时无法删除，MinIO 上传完成前别删
- 更稳妥的做法是：用
os.CreateTemp写临时文件，上传成功后再删，避免和用户上传同名文件冲突
s3:PutObject，或客户端 endpoint 写成 http://localhost:9000 却忘了 MinIO 默认只监听 127.0.0.1，外部请求会被拒绝。 
