c.FormFile() 返回 nil 或 panic 的真实原因是校验方式错误：需检查第二个返回值 *multipart.FileHeader 是否为 nil，而非直接判断 file == nil；同时须确保 enctype="multipart/form-data"、curl 使用 -F 而非 -d、前后端字段名一致，并显式设置 r.MaxMultipartMemory。
c.FormFile() 返回 nil 或 panic 的真实原因
根本不是文件没传过来，而是你用错了校验方式。Go 的 multipart.File 是接口类型，即使底层没数据，接口变量本身也可能非 nil；直接写 if file == nil 永远不成立，后续调 file.Open() 或 io.Copy() 就会 panic。
必须依赖 c.FormFile() 的第二个返回值——*multipart.FileHeader 是否为 nil：
-
file, header, err := c.FormFile("upload")，先检查err != nil - 再判断
header == nil，这才是文件字段为空的可靠依据 - 如果
header != nil但header.Size == 0，说明用户点了“上传”却没选文件（空提交）
enctype 和 curl -F 缺一不可
前端表单漏掉 enctype="multipart/form-data"，或者 curl 里用 -d 代替 -F，Gin 根本不会进 multipart 解析流程——c.FormFile() 拿不到任何东西，日志里只显示 http: no such file。
常见错误组合：
-
curl -X POST -H "Content-Type: application/json" -F "file=@a.jpg"：手动设 JSON 类型，覆盖了 curl 自动加的multipart/form-data; boundary=xxx，后端收不到文件 -
curl -X POST -d "file=@a.jpg" http://localhost:8080/upload：-d 发的是 urlencoded，不是 multipart，c.FormFile()必然失败 - HTML 表单中
name="avatar"，但后端写c.FormFile("file")：字段名大小写/拼写不一致，直接返回 err
r.MaxMultipartMemory 设置不当的隐性崩溃
这个值控制 Gin 在内存中缓存 multipart 请求体的最大字节数，默认 32 MiB。它不是“上传限制”，而是“解析阶段内存上限”。一旦超限，请求在到达路由处理函数前就被拦截，c.FormFile() 根本不会执行，日志里只有 http: request body too large，且 err 是 nil（因为连解析都没开始）。
部署前必须显式设置：
- 在
gin.Default()之后、注册任何路由之前调用，例如：r.MaxMultipartMemory = 50 （50 MiB） - 不要设为 0（不限制），否则恶意上传大文件可耗尽服务器内存
- 该值需略大于业务允许的最大单文件体积，但不必预留冗余——Gin 不会把整个文件都读进内存，只是缓存 header 和小文件内容
保存文件时的三个致命陷阱
c.SaveUploadedFile() 看似简单，但直接拼路径极易出事：
- 目标目录不存在：如
"./uploads/" + header.Filename，但uploads/目录没提前创建，报错open ./uploads/xxx.png: no such file or directory - 工作目录不确定：二进制用 systemd 启动时，当前目录通常是
/，./uploads/就变成//uploads/，写入失败 - 路径遍历攻击：用户传
../../etc/passwd作为文件名，不做清洗就拼接，可能覆盖系统关键文件
正确做法是三步走：os.MkdirAll("uploads", 0755) 确保目录存在 → 用 securejoin.SecureJoin("uploads", sanitizeFilename(header.Filename)) 做路径净化 → 再调 c.SaveUploadedFile()。别省这一步，线上环境出过真实事故。
