c.formfile 返回 nil 或 panic 的根本原因是前端未设置 enctype="multipart/form-data" 或后端字段名不匹配；gin 不会自动解析非 multipart 请求，且 name 必须严格一致（区分大小写、无空格），否则无法获取文件。
c.FormFile 返回 nil 或 panic，基本就卡在前端没设 enctype="multipart/form-data"，或者后端字段名不匹配 —— 其他问题都是在这基础上衍生的。
为什么 c.FormFile 总是返回 nil
这不是 Gin 的 bug，而是 multipart 解析根本没触发或字段压根不存在。
- 前端
<form></form>必须显式写enctype="multipart/form-data"；只写method="post"不够，浏览器会当普通表单发，后端收不到文件数据 -
c.FormFile("avatar")要求前端<input type="file" name="avatar">，name 严格区分大小写、不能有空格或特殊字符 - 如果前端传了多个同名
file字段（比如动态加的 input），c.FormFile只取第一个；要全量处理得用c.MultipartForm()并遍历form.File["files"] - Gin 确实会在调
c.FormFile前自动调ParseMultipartForm，但前提是请求头Content-Type是multipart/form-data且带有效boundary；伪造请求或 curl 漏参数会导致静默失败
保存文件前必须做的三件事
直接 c.SaveUploadedFile(file, "uploads/"+file.Filename) 是线上事故高发操作。
- 校验
file.Size：比如限制 ≤ 5MB，超限立刻c.AbortWithStatusJSON(400, ...)，别等写到磁盘才发现太大 - 检查
file.Header.Get("Content-Type")：只放行"image/jpeg"、"application/pdf"这类白名单 MIME，别信扩展名 —— 用户改个.jpg后缀就能上传.php - 清洗文件名：
path.Base(file.Filename)截掉路径部分，再加 UUID 前缀（如uuid.NewString()+"_"+baseName），防止../../etc/passwd这类路径穿越
c.SaveUploadedFile 报 “no such file or directory” 怎么办
错误信息很直白，但原因常被忽略：它不创建父目录，只往已有路径里写。
- 路径必须是绝对路径，或确保相对路径基准正确 ——
"./uploads/xxx"的.是进程启动目录，不是go.mod所在目录 -
uploads/目录必须提前存在，Gin 不帮你mkdir -p；建议启动时用os.MkdirAll("uploads", 0755)初始化 - 如果你用
filepath.Join(os.TempDir(), "myapp", filename)，注意os.TempDir()在不同系统返回值不同（Linux 是/tmp，Windows 是C:\Users\...\AppData\Local\Temp），别硬编码
并发上传大文件时内存爆满
默认 MaxMultipartMemory = 32 （32MB），10 个用户同时传 20MB 文件，内存就飙到 200MB+，还可能触发 GC 频繁停顿。
- 启动时设
router.MaxMultipartMemory = 64 （64MB）只是权宜之计；更稳的做法是在 handler 里用 <code>c.Request.MultipartReader()流式处理，边读边传云存储，不落地 - 如果必须本地暂存，记得调
defer file.Close()——c.FormFile返回的*multipart.FileHeader里Open()出的文件句柄不会自动关，漏关会导致too many open files - 别在 handler 里用
ioutil.ReadAll或bytes.Buffer读整个文件，2GB 视频直接 OOM；流式处理才是正解
最麻烦的从来不是写对一行 c.FormFile，而是忘记 os.MkdirAll、漏关文件句柄、或把 Content-Type 当成可信输入 —— 这些点在线上扛不住真实流量。
