最简路径c.formfile上线易出错，核心在于跳过表单编码、字段名匹配、解析时机三道关：需设enctype="multipart/form-data"，字段名严格一致，避免重复解析，校验大小与类型，限制maxmultipartmemory，路径清洗防穿越。
直接用 c.FormFile 是最简路径，但只要一上线就容易出错——不是文件拿不到，就是保存失败、内存爆掉、或者被恶意上传打穿服务。核心问题从来不在 Gin 本身，而在于你跳过了三道必须过的关：表单编码、字段名匹配、解析时机。
前端表单没设 enctype="multipart/form-data" 就别谈上传
这是 80% 的“c.FormFile 返回 nil”问题的根源。Gin 不会报错，只是安静地返回 nil, err；浏览器也照常提交，但后端根本收不到文件字段。
-
<form method="POST" action="/upload"></form>—— 缺这个属性，永远拿不到文件 - 必须显式写成
<form method="POST" enctype="multipart/form-data" action="/upload"></form> - 用 JS 构造 FormData 时不用手动设，但用原生表单或 axios.post(..., { data: form }) 时得检查 headers 是否被覆盖
c.FormFile("xxx") 的字段名必须和 <input name="xxx"> 完全一致
大小写、下划线、中划线都敏感。写成 c.FormFile("avatarImg") 但前端是 <input name="avatarimg">，结果就是 file == nil 且 err == nil，极易漏判。
- 调用前先确认
c.Request.MultipartForm() == nil？如果不是，说明已解析过，c.FormFile可能失效 - 多个同名文件（比如
<input type="file" name="files" multiple>）时，c.FormFile只返回第一个；要用c.MultipartForm().File["files"]遍历 - 如果
c.FormFile("files")返回file == nil && err == nil，代表该字段无内容，不是错误，别 panic
保存前不校验 header.Size 和 Content-Type 就等于开门迎客
c.SaveUploadedFile 不做任何安全过滤。用户改个 filename="../../etc/passwd" 或传个 2GB 的 .zip，你的服务要么写穿磁盘，要么 OOM 崩溃。
- 必须先检查
file.Size （例如限制 5MB），超限直接 <code>c.AbortWithStatusJSON(400, ...) - 用
file.Header.Get("Content-Type")判断类型，比如只允许"image/jpeg"、"application/pdf"；别信扩展名 - 目标路径必须用
path.Base(file.Filename)截取文件名，再拼上 UUID 前缀，避免路径穿越和重名 - 确保
./uploads/目录存在，c.SaveUploadedFile不会自动创建父目录
并发大文件上传时 MaxMultipartMemory 不调就等着 OOM
默认 32MB 的 MaxMultipartMemory 是给小图设计的。5 个用户同时传 50MB 文件，光解析阶段就吃掉 1.6GB 内存，还没开始保存。
- 启动时必须设置：
router.MaxMultipartMemory = 8 （8MB），逼迫 Go 标准库流式解析而非全读入内存 - 这数值不是“最大允许上传大小”，只是 multipart 解析缓冲区上限；真正限制还得靠后续
file.Size校验 - 超过这个值，
c.FormFile会返回http.ErrMissingBoundary或静默失败，前端收不到明确提示 - 生产环境大文件必须分片；
c.Request.MultipartReader()才是可控入口，c.FormFile只适合原型验证
真正麻烦的不是写几行 SaveUploadedFile，而是每一步都藏着隐式依赖：前端编码、字段命名、内存配置、路径清洗、类型校验——少一个，上线后就多一个半夜告警。
