如何使用Golang开发文件压缩工具_Golang压缩解压实战

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+。

• 永远用 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()。