直接用 c.MultipartForm() 解析并按字段名分类处理是最可控方式；c.FormFile() 不可靠，仅返回首文件且无法区分字段来源，易漏文件、误判缺失。
直接用 c.MultipartForm() 解析，再按字段名分类处理，是 Gin 中处理多类型文件上传最可控的方式。别依赖循环调用 c.FormFile() —— 它不可靠、易漏文件、且无法区分字段来源。
为什么不能只靠 c.FormFile() 处理多类型上传
前端可能同时发来 avatar、id_card、contract.pdf 等不同 name 的文件字段，也可能多个 photos 字段带 multiple。但 c.FormFile("xxx") 每次只返回第一个匹配项，第二次调用就返回 nil, err（不是重放，是 reader 偏移已耗尽）。你根本拿不到其余字段的文件头。
- 调一次
c.FormFile("avatar")→ 拿到头，但id_card和photos彻底丢失 - 试图循环调
c.FormFile("photos")→ 第二次起err == http.ErrMissingFile，切片为空 - 字段名拼错或前端漏传时，
c.FormFile()返回nil, err，但你无法知道是哪个字段缺失
c.MultipartForm() 返回的 form.File 是怎么组织的
c.MultipartForm() 解析后返回 *multipart.Form，其 form.File 是 map[string][]*multipart.FileHeader 类型：键是表单字段名（如 "avatar"），值是该字段下所有文件头的切片（哪怕只有一个）。
- 前端发
<input type="file" name="avatar">+<input type="file" name="id_card">→form.File["avatar"]和form.File["id_card"]各有一个元素 - 前端发
<input type="file" name="photos" multiple>选了 3 张图 →form.File["photos"]是长度为 3 的切片 - 字段名不存在（比如前端没传
contract）→form.File["contract"]是nil，不是空切片；直接len(form.File["contract"])会 panic
安全遍历每个字段下的所有文件头
必须先检查 key 是否存在、切片是否非 nil，再逐个校验 header 是否有效。空文件（header.Size == 0）和 nil header 都要跳过，否则保存会出错或覆盖目录。
- 用
if headers, ok := form.File["avatar"]; ok && headers != nil判断字段是否存在且有内容 - 对每个
header，先确认header != nil，再检查header.Size > 0 - 不要直接
file, _ := header.Open()—— 必须接收err并判断，header.Open()可能因临时文件不可读失败 - 每个
file打开后，立刻defer file.Close()，但要在打开目标文件之后、io.Copy之前做
大文件或高并发下内存与磁盘的隐性风险
c.MultipartForm() 默认把整个 multipart body 解析进内存（上限 MaxMultipartMemory = 32 << 20），超限才写临时文件。但临时文件路径由 os.TempDir() 决定，若磁盘满、权限不足或 SELinux 限制，会直接报 http: no such file or directory 或 permission denied，而不是友好的错误提示。
- 上线前务必设置
r.MaxMultipartMemory = 8 << 20（8MB）等合理值，避免小请求吃光内存 - 不要假设
os.TempDir()可写 —— 提前在启动时os.Stat()检查并 log warning - 若需支持百 MB 级上传，应放弃
c.MultipartForm()，改用c.Request.Body流式解析（需手动 parse boundary，推荐用mime/multipart.Reader） -
c.SaveUploadedFile()内部硬编码os.Create()，无法控制 umask、无法复用句柄、无法提前校验 content-type —— 生产环境一律用header.Open()+io.Copy()自主控制
真正麻烦的不是“怎么拿到文件”，而是“怎么不 panic、不丢文件、不爆内存、不被绕过校验”。字段名动态、空文件混杂、临时目录不可控——这些细节一旦漏判，线上就挂。
