ZIP打不开主因是FileHeader.Name未设为合法相对路径；解压需校验Name防遍历；tar.gz跨平台支持差；大文件须io.copy流式处理，禁用全量读取；时间戳应显式设置。
用 archive/zip 压缩多个文件时，为什么生成的 ZIP 打不开？
常见原因是没正确设置 zip.FileHeader.Name，导致文件路径混乱或为空。ZIP 规范要求每个文件条目必须有非空、正斜杠分隔的相对路径（不能以 / 开头，也不能含 ..）。windows 资源管理器对非法 Name 特别敏感，直接报“压缩包损坏”。
- 确保
fh.Name是干净的相对路径，例如"docs/readme.txt"，而不是"/home/user/docs/readme.txt"或"../readme.txt" - 用
filepath.ToSlash(filepath.Rel(rootDir, absPath))安全生成归档内路径 - 手动设置
fh.Method = zip.Deflate（默认是 Store，不压缩） - 写入前调用
fw, err := zw.CreateHeader(&fh)，不要跳过这步直接zw.Create()
解压 ZIP 时如何避免目录遍历攻击（../../../etc/passwd）？
go 标准库不会自动校验路径安全性，zip.File.Open() 返回的 reader 可读任意内容，但真正危险的是你调用 os.Create() 时用了未经净化的 f.Name。
- 对每个
zip.File的Name调用strings.HasPrefix(f.Name, "..") || strings.Contains(f.Name, "/../")检查 - 用
filepath.Clean(f.Name)归一化后，再确认是否仍以".."开头或含".."组件 - 更稳妥的做法：提取
filepath.Base(f.Name)作为文件名，强制解压到固定子目录（如"./unzipped/"），忽略原始路径结构 - 别信任
f.IsDir()单独判断——恶意 ZIP 可伪造Name = "etc/passwd/"让它返回 true
archive/tar + gzip 打包比 zip 快，但为啥 macOS/linux 上默认打不开？
TAR.GZ 不是单个文件格式，而是两层封装：tar 打包 + gzip 压缩。macOS Finder 和 windows 资源管理器只原生支持 ZIP，不识别 .tar.gz。用户双击会提示“无法打开”，除非装了 The Unarchiver 或 Keka。
- 用
tar.NewWriter写入文件时，Header.Name同样要 clean，且不能以/开头 - gzip 层必须在 tar 外层：先
gzip.NewWriter(f)，再传给tar.NewWriter()，顺序反了会生成无效流 - 如果目标用户主要是 macos/Linux 终端用户，TAR.GZ 更轻量；若需跨平台开箱即用，坚持用
archive/zip - 注意：tar 不自带文件权限加密，敏感信息别依赖它做安全隔离
大文件压缩卡住或内存爆掉，怎么流式处理？
把整个文件读进 []byte 再写入 zip/tar 是最常见内存杀手。尤其是压缩几百 MB 日志时，Go 程序 RSS 直接飙到 2GB+。
立即学习“go语言免费学习笔记（深入）”；
- 永远用
io.Copy()流式传输：打开源文件 →fw, _ := zw.CreateHeader(&fh)→io.Copy(fw, srcFile) - 避免
os.ReadFile()或bytes.Buffer缓存全文本 - 对超大单文件（>1GB），可配合
io.LimitReader()分块处理，但一般没必要——标准io.Copy默认 32KB 缓冲已足够 - 如果并发压缩多个文件，注意控制 goroutine 数量，用
semaphore限制同时打开的文件句柄数，防止too many open files
实际项目里最容易被忽略的，是 ZIP 文件时间戳的默认值——fh.ModTime 若为零值，部分解压工具（如 7-Zip）会显示错误日期，甚至影响某些构建流程的缓存判定。记得显式赋值 fh.ModTime = time.Now() 或从源文件取 fi.ModTime()。