Go 的 zip.Writer 默认不压缩、不设时间戳、不处理路径和编码，需显式设置 header.Method=zip.Deflate、header.Modified、filepath.Clean、UTF-8标志（Flags|=0x800）等，否则导致体积大、乱码、Zip Slip 漏洞等问题。
archive/zip 创建 zip 包必须手动设 header.Method = zip.Deflate，否则只是归档，不是压缩。
很多人发现用 Go 打出的 .zip 文件体积和源文件几乎一样，解压后时间戳全为 1970 年，打开还乱码——根本原因不是“Go 压缩不行”，而是默认用 zip.Store（即无压缩存储），且没设时间、没标编码、路径也没清理。
关键点在于：zip.Writer 不是“点一下就压缩”的黑盒，它只负责按 ZIP 格式把数据流写进去，压缩、路径、编码、时间，全得你显式控制。
为什么 zip.Writer.CreateHeader 调用后必须检查 err
这个函数会静默校验 header.Name：如果含 ../、以 / 开头、含非法字符（如 Windows 的 : 或 ?），它直接返回 error，但不会 panic，也不中断后续流程。结果就是 ZIP 看似生成成功，实际内部结构损坏，Windows 资源管理器打不开，unzip -t 报 “invalid central directory”。
立即学习“go语言免费学习笔记（深入）”；
-
header.Name必须是正斜杠分隔的相对路径，用filepath.ToSlash(filepath.Clean(relPath))处理 - 绝对路径（如
/home/user/file.txt）或带盘符（如C:\data\file.txt）会被拒绝写入 - 用户上传的原始文件名绝不能直传，需白名单过滤（如只允许
[a-zA-Z0-9._-]+/） - 每次调用
writer.CreateHeader(header)后必须写if err != nil { return err }
解压时不做 filepath.Clean + 前缀校验，等于开放任意文件写入
攻击者构造一个名字为 ../../../etc/shadow 的条目，不校验就直接 os.OpenFile(filepath.Join(dst, f.Name), ...)，你的服务就可能把敏感文件覆盖掉——这就是 Zip Slip 漏洞，2026 年仍高频出现在 CI/CD 和文件共享服务中。
- 先用
filepath.Clean(f.Name)归一化路径（把..\、./、重复/全干掉） - 再判断是否仍含
".."或以"/"开头，有则跳过 - 更安全做法：算出目标绝对路径
dstAbs, _ := filepath.Abs(dstDir)，再检查cleanedPath拼接后是否仍以dstAbs开头（用strings.HasPrefix(filepath.ToSlash(absDstPath), filepath.ToSlash(expected))） - 遇到
f.IsDir()为 true 的条目，也要调用os.MkdirAll(..., 0755)，别指望自动建目录
header.Flags |= 0x800 是中文文件名在 Windows 上不乱码的关键
Go 默认按 UTF-8 写文件名，但旧版 Windows 资源管理器（Win7/Win10 早期版）默认用 GBK 解码，导致中文显示成 .txt。设 header.Flags = 0x800（即 1 ）告诉解压工具：“这名字是 UTF-8 编码的”。macOS/Linux 和新版 Windows（11+）、7-Zip、Bandizip 都认这个标志。
- 别用
header.Flags = 1—— 这是老标准，兼容性差；0x800是 ZIP APPNOTE 6.3.4 明确定义的 UTF-8 标志位 - Go 1.22+ 提供了
header.SetUTF8(true)，效果等价，更语义化 - 如果必须支持 Win7 自带解压器，就得用
golang.org/x/text/encoding/charmap转 GBK，再清空Flags，但此时 Linux 下会乱码——没有通用解法，只能按目标环境选 - 空目录要显式加尾部斜杠：
header.Name += "/"，否则很多解压工具识别不了
最常被忽略的不是语法，是资源关闭和路径净化：解压时 file.Open() 返回的 io.ReadCloser 必须 defer rc.Close()，否则几百个 zip 循环处理就会触发 too many open files；压缩时 writer.Close() 漏掉，ZIP 就缺中央目录，连 unzip -l 都列不出来。
