直接用http.ServeFile无法满足打包下载需求，因其仅支持单个文件返回，而打包下载需动态生成ZIP并流式响应；必须手动设置Content-Type、Content-Disposition（含URL编码）、Content-Transfer-Encoding等头部，且用archive/zip直接写入c.Writer，调用w.Close()确保ZIP结构完整。
为什么直接用 http.ServeFile 无法满足打包下载需求
因为 http.ServeFile 只能返回单个文件，而打包下载本质是动态生成 ZIP 并流式响应。Gin 的 c.Writer 虽然支持写入，但若不手动设置 Header 和 Content-Type，浏览器会尝试解析 ZIP 二进制内容导致乱码或崩溃。
- 常见错误现象：
ERR_INVALID_RESPONSE或下载后解压提示“文件已损坏” - 关键遗漏点：没调用
c.Writer.Header().Set("Content-Transfer-Encoding", "binary") - 必须显式设置
Content-Disposition，否则 Safari/Edge 可能忽略文件名 - ZIP 包含中文路径时，需用
zip.FileHeader.SetModTime避免时间戳异常影响解压
如何用 archive/zip 动态构建 ZIP 并写入 c.Writer
不要先写到磁盘再读取——既慢又占内存。应直接向 c.Writer 写入 ZIP 流，同时控制 HTTP 头部。
- 先调用
c.Writer.Header().Set("Content-Type", "application/zip") - 再设
Content-Disposition: attachment; filename="xxx.zip"，注意 filename 值需 URL 编码（尤其含中文） - 创建
zip.NewWriter(c.Writer)，逐个调用w.CreateHeader(&zip.FileHeader{...})添加文件 - 每个文件内容用
io.Copy(fileWriter, fileReader)写入，避免一次性加载大文件到内存 - 最后务必调用
w.Close()，否则 ZIP 结尾结构缺失，解压失败
如何安全读取待打包的文件路径，防止目录遍历攻击
用户传来的 file_paths 参数（如 ["../etc/passwd", "a.txt"]）必须校验，否则可能泄露服务器任意文件。
- 禁止使用
filepath.Join(baseDir, userPath)直接拼接 - 正确做法：用
filepath.Clean(userPath)归一化路径，再检查是否以白名单根目录开头（如strings.HasPrefix(cleaned, baseDir)） - 更稳妥方式：将所有待打包路径转为绝对路径，再用
filepath.Rel(baseDir, absPath)判断是否在允许范围内 - 若路径校验失败，立即返回
c.AbortWithStatus(400)，不进入 ZIP 构建流程
大文件打包时如何避免内存溢出和超时
Gin 默认读写超时是 30 秒，ZIP 流式写入过程中若某文件读取慢（如 NFS 挂载），会导致整个请求卡住并超时。
立即学习“go语言免费学习笔记（深入）”；
- 对每个文件读取加 context timeout，例如
ctx, cancel := context.WithTimeout(r.Context(), 10*time.Second) - 用
http.MaxBytesReader包裹c.Request.Body（如果接收上传清单）防止恶意大 body - 禁用 Gin 的自动 gzip 压缩（
router.Use(gin.Gzip())），ZIP 本身已压缩，再 gzip 反而增大体积且耗 CPU - 生产环境建议加
Content-Length？不行——流式 ZIP 无法预知总大小，只能省略该 header
w.Close() 调用时机和 Content-Disposition 中 filename 的编码处理；这两处出错，前端看起来“下载成功”，但 ZIP 实际不可用。 
