ctx.formfile无法直接读取压缩包内文件，因它仅返回原始上传的zip文件头，不解压内容；需用zip.newreader解包并严格校验子文件路径防穿越。
为什么 ctx.FormFile 无法直接读取压缩包里的文件？
因为 ctx.FormFile 只能拿到前端上传的原始 multipart/form-data 中的单个文件对象，它不解析压缩包内容。你传一个 archive.zip，Gin 就只给你这个 zip 文件的 *multipart.FileHeader，里面没有“解压后里面的 config.json”——那是你自己的业务逻辑要干的事。
常见错误现象：file, err := ctx.FormFile("file") 成功了，但后续想直接 json.Unmarshal 却报 invalid character 'PK' looking for beginning of value，这就是在拿 zip 二进制当 JSON 解析。
- 必须先用
file.Open()获取io.ReadCloser - 再用
zip.NewReader或archive/tar解包（取决于实际格式） - 遍历
zip.File列表，按需打开子文件（注意检查路径安全性，防../路径穿越）
如何安全解压并提取指定类型子文件？
重点不是“怎么解压”，而是“怎么避免把 ../../../etc/passwd 写到服务器上”。Gin 不负责校验 zip 内路径，这得你自己做。
实操建议：
- 用
filepath.Clean规范化每个zip.File.Name，再检查是否以"."开头或含".." - 限制解压目标目录为临时目录（如
os.MkdirTemp("", "upload-")），而非直接写入业务路径 - 若只需读取某个子文件（比如
payload.yaml），别全量解压：用zipFile.Open()直接获取其io.ReadCloser，传给yaml.Unmarshal或其他解析器 - 注意
zip.File的Mode()可能是目录（os.ModeDir），跳过或忽略
示例片段：
zipReader, err := zip.NewReader(fileContent, file.Size)
if err != nil { return err }
for _, f := range zipReader.File {
if strings.Contains(f.Name, "..") || strings.HasPrefix(filepath.Clean(f.Name), ".") {
continue // 拒绝危险路径
}
if f.Name == "data.json" {
rc, err := f.Open()
if err != nil { continue }
defer rc.Close()
json.NewDecoder(rc).Decode(&payload)
break
}
}
ctx.Request.MultipartForm 和 ctx.FormFile 选哪个？
绝大多数场景下用 ctx.FormFile 就够了。它本质是 ctx.Request.MultipartForm 的封装，自动调用 ParseMultipartForm 并返回指定字段的文件头。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
只有当你需要同时接收多个同名文件（<input type="file" multiple>）、或需要访问同请求中的其他表单字段（ctx.PostForm("type")）且担心并发调用冲突时，才显式用 MultipartForm：
-
ctx.Request.MultipartForm是惰性解析，首次调用才真正 parse；多次调用不会重复解析，但要注意它会把整个 multipart body 读进内存（受MaxMultipartMemory限制） -
ctx.FormFile内部也走同一套流程，更简洁，推荐优先使用 - 如果上传体积大（>32MB），记得提前设置
gin.SetMode(gin.ReleaseMode)和router.MaxMultipartMemory = 1024 * 1024 * 100（100MB）
gzip 压缩的 HTTP 请求体 vs. 上传的 .zip 文件，别混淆
这是两个完全不同的压缩层：一个是传输层（HTTP Content-Encoding: gzip），一个是业务层（用户上传一个 .zip 文件）。Gin 默认不自动解 gzip 请求体，但大多数反向代理（Nginx、ALB）会默认透传或解压，导致你收到的是已解压的原始 multipart 数据——所以你代码里看到的 file.Size 是解压后大小，不是 zip 包大小。
验证方式：打印 ctx.GetHeader("Content-Encoding")，如果值是 gzip，说明客户端对整个请求体做了 gzip，此时 ctx.Request.Body 已被 Gin 自动解包（依赖 net/http 的标准行为），你无需额外处理；但如果是上传一个 zip 文件，header 里不会有 Content-Encoding，file.Size 就是 zip 包原始字节数。
容易踩的坑：误以为“上传压缩包”就等于“HTTP 被压缩”，结果在 Nginx 配置里关了 gzip off，反而让某些客户端因不兼容出错。
实际解压逻辑本身不难，难的是路径校验、资源释放（defer rc.Close() 别漏）、以及区分清楚“谁在压缩、在哪一层压缩”。这些细节不处理好，轻则解析失败，重则引发路径穿越或内存泄漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
