c.FormFile更适合单文件上传，因其自动完成边界解析、内存/临时磁盘缓冲选择及文件头校验；而c.MultipartForm需手动处理*multipart.Form，易因未设ParseMultipartForm或MaxMemory导致OOM或缓冲溢出。
为什么 c.FormFile 比 c.MultipartForm 更适合上传单图
直接调用 c.FormFile("file") 是 Gin 处理单文件上传最简路径，它自动完成边界解析、内存/临时磁盘缓冲选择、文件头校验。而 c.MultipartForm 需手动处理 *multipart.Form，容易漏掉 ParseMultipartForm 调用或忽略 MaxMemory 限制，导致大文件直接 OOM。
常见错误现象：http: request body too large 或 multipart: NextPart: bufio: buffer full —— 这通常是因为没提前设置 c.Request.ParseMultipartForm(32 （32MB）。
- 必须在
c.FormFile前调用c.Request.ParseMultipartForm，否则可能 panic -
FormFile返回的*multipart.FileHeader包含Size、Header、Filename，但不包含内容；需用file.Open()读取 - Gin 默认
MaxMemory是 32MB，超限部分写入临时磁盘，不影响可用性，但要注意磁盘空间和清理
如何安全保存上传的图片并防止覆盖或路径遍历
别直接用 header.Filename 作保存名 —— 它可能含 ../../etc/passwd 或空格、中文、特殊符号，既不安全也不利于 CDN 分发。
- 用
filepath.Base(header.Filename)截掉路径部分，再用strings.ReplaceAll清除非法字符 - 强制重命名：推荐用
uuid.New().String() + filepath.Ext(filename)，避免冲突且无信息泄露 - 保存前检查
header.Size是否超出业务允许上限（如 5MB），直接c.AbortWithStatusJSON(400, "file too large") - 用
mimetype := header.Header.Get("Content-Type")校验是否为image/jpeg、image/png等，但注意该字段可被伪造，关键场景应读取文件头（如用github.com/h2non/filetype）
怎样返回标准 JSON 响应并支持前端预览
上传成功后只返回原始文件名或路径，前端无法直接预览 —— 必须提供可访问的 URL。Gin 不内置静态服务，需额外配置路由或交由 Nginx 处理。
- 保存路径建议统一到
./uploads/，然后注册静态路由：r.Static("/uploads", "./uploads") - 响应结构推荐：
{"code": 0, "url": "/uploads/abc123.jpg", "size": 204800}，不要嵌套多层 - 如果部署在子路径（如
/api/upload），URL 要拼接完整 base URL，别依赖相对路径 - 设置响应头
c.Header("Content-Type", "application/json; charset=utf-8")，避免某些 IE 版本乱码
并发上传时文件写入失败或磁盘满怎么办
多个请求同时写入同一目录，若没做并发控制或磁盘监控，会出现 open ./uploads/xxx.jpg: no such file or directory（父目录不存在）或 no space left on device。
- 保存前确保目录存在：
os.MkdirAll("./uploads", 0755)，不要假设目录已建好 - 用
os.CreateTemp("./uploads", "upload-*.jpg")生成唯一临时文件，再os.Rename，比直接os.Create更健壮 - 记录磁盘使用率（
unix.Statfs或golang.org/x/sys/unix），达到 90% 时主动拒绝新上传并告警 - 上传完成后，不要立即
defer file.Close()，要检查io.Copy是否返回非 nil error
