c.formfile() 不防恶意脚本，因其仅提取文件元信息与句柄，不校验后缀、mime或内容；真正防护需三层校验（扩展名白名单+content-type参考+net/http.detectcontenttype探测）、路径隔离、独立域名存储及全局限流。
为什么 c.FormFile() 本身不防恶意脚本
c.FormFile() 只负责从 multipart/form-data 中提取文件元信息和句柄，它不做任何内容检查——上传 shell.php、rev.jsp 或带恶意 EXIF 的 photo.jpg，它都照单全收。框架不会扫描文件头、不校验后缀、不解析内容，这是设计使然：职责分离，安全应由业务层显式控制。
必须做的三道防线：后缀 + MIME + 内容检测
单靠过滤后缀或只看 Content-Type 都不可信，攻击者能轻易伪造。真正有效的组合是三层校验：
- 用
filepath.Ext()提取扩展名，白名单严格比对（如只允许.jpg、.png、.pdf）；禁止.php、.jsp、.sh等可执行或服务端解析类型 - 调用
header.Header.Get("Content-Type")获取客户端声明的 MIME，但仅作参考；同时用net/http.DetectContentType()读取前 512 字节做实际探测，防止伪造 - 对图片类文件，额外用
image.DecodeConfig()尝试解析尺寸——恶意构造的“图片”常在此步 panic 或返回无效宽高
上传路径与保存方式必须隔离执行环境
即使文件内容安全，若保存路径可控或被拼接进命令，仍可能触发路径遍历或命令注入：
- 绝对不要用
c.PostForm("filename")直接拼接保存路径；必须用securejoin.SecureJoin("uploads", sanitizeFilename(header.Filename))清洗 - 上传目录不能是 Web Server 的静态资源根目录（如 Nginx 的
root /var/www），否则upload/shell.php可能被直接执行 - 生产环境建议将上传文件存到独立域名（如
https://files.example.com/xxx.jpg），且该域名后端不解析 PHP/JS 等脚本
别忽略中间件提前读取导致的限流失效
很多团队配了 router.MaxMultipartMemory 或 gin.SetMode(gin.ReleaseMode) 就以为安全了，但真实漏洞常出在中间件里：
- JWT 验证中间件若调用了
c.Request.ParseForm()或io.ReadAll(c.Request.Body)，会提前耗尽r.Body，后续c.FormFile()拿不到数据，而MaxBytesReader包装也已失效 - 正确做法是在所有中间件之前，用
http.MaxBytesHandler全局包裹整个gin.Engine，或在路由匹配后、handler 执行前，用MaxBytesReader动态赋值r.Body - 特别注意：Gin v1.9+ 默认启用了
DefaultWriter的限流，但自定义gin.New()实例时这个开关可能被关掉，需手动确认
