c.formfile 返回 nil 的根本原因是请求未正确发送或请求体被提前读取；常见情况包括name不匹配、content-type缺失、body被预先消费、超出内存限制且临时目录不可写。
c.FormFile 为什么返回 nil？
根本原因不是 Gin 本身有问题，而是请求没发对或中间被提前消费了。c.FormFile 返回 nil 时，90% 是以下几种情况之一：
- 前端
<input name="file">的 name 和后端c.FormFile("file")的字符串不一致（大小写、下划线、空格都算不同） - 请求头缺失
Content-Type: multipart/form-data; boundary=...，尤其是用curl或 Postman 手动构造时硬编码了 boundary，而没让客户端自动生成 - 在调用
c.FormFile前，已执行过c.PostForm、c.Request.Body.Read或任何触发ParseMultipartForm的操作，导致 body 被读空 - 上传文件超过
router.MaxMultipartMemory限制（默认 32MB），且磁盘临时目录不可写或权限不足，此时c.FormFile会直接报http: no such file
c.FormFile 和 c.MultipartForm 怎么选？
二者解析时机和内存行为完全不同，选错会导致性能问题或逻辑错误：
-
c.FormFile("avatar")：按需解析单个字段，只加载该文件的*multipart.FileHeader，适合头像、简历等明确单字段场景；不触发全量解析，内存友好 -
c.MultipartForm()：一次性把整个 multipart body 解析进内存，返回*multipart.Form，其中form.File是map[string][]*multipart.FileHeader，支持同名多文件（如<input type="file" name="photos" multiple>）和混合表单字段读取 - 注意：
c.MultipartForm()在高并发小文件上传时可能吃内存，而c.FormFile每次只开销一个 header 结构体，更轻量
保存前必须校验的三件事
不校验就 c.SaveUploadedFile，等于把服务器门钥匙交给任意上传者：
- 检查
file.Header.Filename是否含路径遍历字符（如../或%2e%2e/），否则可能覆盖系统文件 - 用
file.Header.Header.Get("Content-Type")判断 MIME 类型，而非仅依赖扩展名；例如拒绝text/php即使文件名叫1.jpg - 限制文件大小：通过
file.Size比较阈值，或更早地在router.MaxMultipartMemory层拦截超大请求（避免临时文件写入失败再报错）
curl 测试时容易漏掉的关键点
用 curl -F 测试时，看似简单，但边界细节决定成败：
-
-F "file=@path/to/file"是正确写法；-F "file=path/to/file"（漏掉 @）只会传文件路径字符串，不是二进制内容 - 不要手动加
-H "Content-Type: multipart/form-data"——curl -F会自动设置并生成合法 boundary；加了反而可能破坏结构 - 如果后端字段是
"upload"，curl必须写成-F "upload=@xxx"，名字必须完全一致 - 上传空文件时，
c.FormFile返回nil, err，但err是http.ErrMissingFile，不是通用 error，建议显式判断
c.Request.Body 的一次性特性 —— 它不像 Python 的 request.files 那样可重复读。一旦被消耗，后续所有文件解析都会失效。这个点不踩一次坑很难真正记住。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
