c.FormFile拿不到文件的根源是前端未正确发送multipart/form-data请求或Gin配置不当：需确保Content-Type含正确boundary、字段名与input name严格一致、未提前读取Body、磁盘权限正常且文件大小未超限。
为什么 c.FormFile 拿不到文件？常见 400 错误的根源
因为前端没发对，或者 Gin 没配好解析边界。Gin 默认只解析 Content-Type: multipart/form-data，但必须带正确的 boundary，而浏览器表单自动处理，curl 或 Postman 手动构造时容易漏掉或写错。
- 检查请求头是否含
Content-Type: multipart/form-data; boundary=...，不能手写死 boundary，应让客户端自动生成 - 后端调用
c.FormFile("file")前，确保字段名（如"file"）和前端<input name="file">完全一致，大小写敏感 - Gin 不会自动解析 multipart body，但
c.FormFile和c.MultipartForm内部会触发一次解析；如果先调用了c.PostForm或读了c.Request.Body，body 就被消耗掉了，再调c.FormFile会返回nil, err - 默认最大内存缓存是 32MB，超限会写临时文件，但若磁盘不可写或权限不足，
c.FormFile会直接报http: no such file类错误
c.MultipartForm 和 c.FormFile 怎么选？
单文件上传用 c.FormFile 更轻量；需要同时读多个文件 + 表单字段，或要校验所有文件再统一处理，就该用 c.MultipartForm。
-
c.FormFile("avatar")返回单个*multipart.FileHeader，适合头像、简历等明确单字段场景 -
form, err := c.MultipartForm()返回完整*multipart.Form，其中form.File是map[string][]*multipart.FileHeader，支持同名多文件（如<input type="file" name="photos" multiple>） - 注意：
c.MultipartForm会一次性把全部文件 header 和表单值都解析进内存，大并发上传时可能吃内存；c.FormFile是按需解析，更省资源
保存文件前必须校验的三件事
不校验就存，轻则覆盖、重则 RCE（比如上传 .php 文件到静态目录）。
- 检查
header.Size，避免空文件或超大文件（如限制 ≤20MB）：if header.Size > 20<code>1024*1024 { c.AbortWithStatusJSON(400, "file too large") } - 用
path.Base(header.Filename)取原始文件名，再用strings.ToLower(filepath.Ext(name))提取扩展名，白名单过滤（如只允许.jpg,.png,.pdf） - 用
filepath.Join(uploadDir, uuid.New().String()+ext)生成唯一文件名，绝不直接用header.Filename—— 它可能含../../etc/passwd路径遍历
多文件上传时，c.Request.MultipartReader() 有什么用？
当文件太多、太大，或你想流式处理（比如边上传边转码、边存对象存储），就不能依赖 Gin 封装好的 FormFile，得自己接管 reader。
立即学习“go语言免费学习笔记（深入）”；
-
reader, err := c.Request.MultipartReader()返回底层*multipart.Reader，可逐个读Part，不受 Gin 默认 32MB 内存限制 - 每个
part调part.FileName()和part.Header.Get("Content-Type")获取元信息，再用io.Copy流式写入磁盘或上传 OSS - 注意：一旦调了
MultipartReader，就不能再用c.FormFile或c.MultipartForm，Gin 的解析逻辑会被绕过
文件上传看着简单，但边界条件极多：空文件、超长文件名、恶意扩展名、重复字段、中文名编码、Nginx 代理截断、容器里 /tmp 权限不对……真正上线前，至少拿 curl -F 发 10 种异常 case 过一遍。
