Go标准库archive/zip可通过file.UncompressedSize64()和file.CompressedSize64()分别获取原始与压缩后大小，需遍历zip.Reader.File列表且避免误用gzip；压缩比=CompressedSize64/UncompressedSize64，STORE方法时比值为1.0。
用 archive/zip 读取原始文件大小和压缩后大小
Go 标准库不直接提供“压缩比计算”函数，但 archive/zip 可以让你手动获取压缩前后的字节量。关键不是打包，而是模拟压缩过程并提取两个数值：原始内容长度（file.Size()）和 ZIP 条目中实际写入的压缩数据长度（file.CompressedSize64()）。注意：必须先调用 zip.ReadCloser.Open() 或遍历 Reader.File 列表，否则 CompressedSize64 可能为 0。
常见错误是直接对单个 os.File 调用 Stat().Size() 就当“原始大小”，忽略了 ZIP 中可能含多个文件、目录结构、或元数据开销。真实压缩比应基于每个条目单独算，再加权平均或分别展示。
- 压缩比 =
float64(file.CompressedSize64()) / float64(file.UncompressedSize64()) - 若
file.UncompressedSize64() == 0，跳过该条目（如空目录） - ZIP 文件本身有全局头部和中央目录，总文件大小 ≠ 所有
CompressedSize64之和
避免用 gzip 替代 zip 导致结果不可比
有人会误用 compress/gzip 包去压一个文件再对比大小，这看似简单，但和 ZIP 压缩比无直接可比性：ZIP 默认使用 DEFLATE，但支持 STORE（不压缩）、DEFLATE、LZMA 等多种方法；而 gzip 固定只用 DEFLATE，且没有文件名、权限、时间戳等元数据开销。你算出来的“压缩比”其实是纯 payload 压缩率，不是用户实际看到的 ZIP 文件体积节省效果。
如果你的目标是分析用户导出的 ZIP 包（比如备份工具、CI 构建产物），就必须解析 ZIP 结构本身，而不是重走一遍压缩流程。
立即学习“go语言免费学习笔记（深入）”；
-
zip.File.Method为zip.Store时，CompressedSize64 == UncompressedSize64，压缩比为 1.0 -
zip.File.Method == zip.Deflate才代表真正压缩，此时才值得计算比值 - 别把
gzip.NewReader应用到 .zip 文件上——会报invalid gzip header
处理中文路径或特殊字符时确保 zip.Reader 正确解码
很多 ZIP 工具（尤其是 Windows 下的）默认用 GBK 或 CP437 编码文件名，而 Go 的 archive/zip 默认按 UTF-8 解析。结果就是 file.Name 显示乱码，甚至 file.FileInfo().IsDir() 判断失败，导致目录统计错位、跳过本该计入的文件。
标准库不内置编码切换，需手动预处理：读取 file.Name 后，检查是否含非法 UTF-8 字节（utf8.ValidString(name)），若否，尝试用 golang.org/x/text/encoding 中的 gbk.NewDecoder().String(name) 还原。但这不影响大小计算——UncompressedSize64 和 CompressedSize64 是二进制字段，与文件名编码无关。
- 压缩比分析本身不依赖文件名，但按类型/扩展名分组统计时，乱码会导致
path.Ext()失效 - 若只需整体比值，可完全忽略
file.Name，只循环zipReader.File切片 - 遇到
zip: not a valid zip file，先用file -i archive.zip确认是不是 ZIP，而非 RAR/7z
小文件太多时注意内存和性能陷阱
一个含 10 万个小文件的 ZIP，用 zip.OpenReader 加载后，Reader.File 是全量切片，每个 *zip.File 占约 200+ 字节，光结构体就吃掉 20MB 内存。更糟的是，如果对每个文件都调用 file.Open() 再 io.Copy(ioutil.Discard, ...)，会触发大量小 IO，拖慢分析速度。
其实不需要打开文件流——所有需要的字段（Name、UncompressedSize64、CompressedSize64、Method）都在 ZIP 目录项里，已由 OpenReader 一次性解析完成。
- 别写
f, _ := file.Open(); f.Close()，纯属浪费 - 统计前先过滤：
if file.UncompressedSize64 ，排除极小文件干扰比值 - 用
runtime.GC()不解决问题；真要处理超大 ZIP，考虑流式解析（但标准库不支持，得换github.com/klauspost/compress或自研）
压缩比数字本身容易误导——同样两个文件，ZIP 里存成一个条目还是分开，中央目录大小不同；STORE 和 DEFLATE 混用会让平均值失去意义。真正有用的不是“整体压缩比”，而是按文件类型、大小区间、压缩方法分组输出，再看哪些类文件几乎没被压缩（比如已压缩的 .jpg、.mp4），那些才是优化切入点。
