Golang如何压缩和解压zip文件_Golang zip压缩解压教程【指南】

Golang如何压缩和解压zip文件_Golang zip压缩解压教程【指南】

在Go语言中处理ZIP文件，看似调用几个标准库函数就能搞定，但实际开发中，有几个“坑”如果不提前了解，很容易导致功能异常甚至安全风险。下面就来聊聊这些关键细节。

zip.Writer默认不压缩，必须显式设header.Method = zip.Deflate

有没有遇到过这种情况：代码跑通了，生成的.zip文件却一点没变小？问题很可能不在你的逻辑，而在于zip.Writer的默认行为——它用的是zip.Store方法，也就是只打包、不压缩。文件会被原封不动地塞进ZIP容器，连zlib都不会调用。

• 关键一步：在写入每个文件前，必须手动设置header.Method = zip.Deflate，否则得到的只是一个“伪压缩包”。
• 唯一选项：zip.Deflate是Go标准库唯一支持的压缩方法，别费心去找像zip.BestCompression这样的常量，它不存在。
• 特殊情况：对于空文件或极小的文件，即使设置了Deflate，底层的zlib也可能自动回退到Store模式，这属于正常优化，并非bug。
• 效率边界：对已经高度压缩的格式（如JPEG、PNG、MP4）再次压缩，效果微乎其微，体积甚至可能略微增加；压缩的收益主要体现在文本类文件上，比如JSON、Go源码等。

zip.Writer默认使用zip.Store不压缩，需显式设置header.Method = zip.Deflate才能启用Deflate压缩；Go标准库仅支持该方法，且空或极小文件压缩效果不明显。

解压时不做路径净化，../../../etc/passwd会直接覆盖系统文件

这是一个经典的安全陷阱。Go的archive/zip包对FileHeader.Name字段采取完全信任的态度，不进行校验、拦截或警告。如果攻击者在ZIP包中放入一个名为../../config.yaml的文件，而你的解压代码简单地使用filepath.Join(dst, f.Name)拼接路径，结果就可能覆盖服务器上的关键配置文件，甚至系统文件——这就是所谓的Zip Slip漏洞。

• 第一步：路径归一化：对每个f.Name，首先调用filepath.Clean(f.Name)进行清理（例如./a/../b会变成b，但../x仍为../x）。
• 第二步：安全检查：检查清理后的路径是否仍包含相对路径前缀或绝对路径。一个简单的判断条件是：cleanPath != f.Name || strings.HasPrefix(cleanPath, "..") || strings.HasPrefix(cleanPath, "/")。
• 第三步：目标确认：使用dstPath := filepath.Join(outputDir, cleanPath)得到最终目标路径后，务必确认filepath.ToSlash(dstPath)确实以filepath.ToSlash(absDest)开头，确保文件被解压到预定目录内。
• 跨平台注意：在Windows系统下，还需要统一将路径转为小写，并将反斜杠"\"替换为斜杠"/"，否则像"..\..\etc\passwd"这样的路径可能会绕过检查。

中文文件名乱码，不是 Go 有问题，是 ZIP 打包方用了 GBK 编码

解压ZIP时遇到中文文件名变成乱码？这通常不是Go语言的“锅”。问题根源在于，许多由Windows资源管理器或旧版压缩工具创建的ZIP文件，其文件名默认使用GBK（或GB18030）编码存储。而Go的archive/zip包始终按照UTF-8编码来解析Header.Name字段，编码不匹配，自然就显示为一堆问号。

• 治本之策：建议文件提供方在打包时使用UTF-8编码。例如，使用7-Zip时勾选“UTF-8”选项，macOS系统默认即为UTF-8，Linux下可使用zip -U命令。
• 兼容方案：如果必须处理来自各方的GBK编码ZIP文件，可以使用golang.org/x/text/encoding/simplifiedchinese包进行手动解码：decoded, _ := gbk.NewDecoder().String(f.Name)。
• 新特性参考：Go 1.22及以上版本尝试引入了zr.RegisterDecompressor(zip.FormatUTF8, ...)的支持，但并非所有ZIP打包工具都会正确设置相关的标志位，因此不能完全依赖此特性。

大文件解压卡死或 OOM，是因为误把整个 ZIP 读进内存

处理大体积ZIP文件时，程序突然卡死或内存溢出（OOM）？一个常见的错误模式是：data, _ := io.ReadAll(zipFile)，然后将整个字节数组传给zip.NewReader(bytes.NewReader(data), ...)。一个几百MB的ZIP文件被完整读入内存，资源消耗可想而知。其实archive/zip本身支持流式读取，问题往往出在使用方式上。

立即学习“go语言免费学习笔记（深入）”；

• 从磁盘解压：优先使用zip.OpenReader(path)。这个函数内部基于os.File和io.Seeker，可以按需读取ZIP文件的目录区和各个文件数据块，避免一次性加载。
• 从网络流解压：网络流不具备随机读取能力，因此必须先完整缓存到本地（例如使用io.ReadAll(resp.Body)），因为archive/zip不支持边下载边解压。切记不要复用原始的resp.Body。
• 写入文件：解压每个文件时，始终使用io.Copy(dst, src)进行流式写入，避免使用io.ReadAll(src)将整个文件内容读入内存再写入。
• 资源清理：别忘了defer r.Close()。文件描述符泄露会导致后续文件操作被阻塞，甚至耗尽系统资源。

说到底，在Go中处理ZIP文件，真正的挑战往往不在于API调用本身，而在于那些容易被忽略的细节：filepath.Clean之后是否还需要用strings.Contains再检查一遍".."？调用os.MkdirAll创建目录时，能否信任ZIP文件头里的f.Mode()？为什么命令行工具unzip -t报错，而Go程序却静默成功了？这些“坑”，不亲自踩一遍，代码就很难真正稳定可靠地上线。