Go语言用archive/zip读取ZIP文件并统计压缩比，需遍历zip.File条目，用UncompressedSize64与CompressedSize64计算比值，跳过目录、加密项及CompressedSize64为0的条目，按区间分类标记（膨胀/无压缩/有效压缩），推荐使用中位数而非平均值汇总。
用 archive/zip 读取 ZIP 文件并统计各文件压缩比
Go 标准库的 archive/zip 可以直接打开 ZIP 文件并遍历条目，无需解压到磁盘。关键在于每个 *zip.File 对象自带 FileHeader，其中 UncompressedSize64 和 CompressedSize64 就是计算压缩比所需的原始大小和压缩后大小。
注意：ZIP 中某些条目（如目录、符号链接）可能没有实际内容，CompressedSize64 为 0，此时除零会 panic，必须跳过。
- 用
zip.OpenReader打开 ZIP 文件，避免手动管理io.ReadCloser - 遍历时检查
f.IsDir()或f.CompressedSize64 == 0，跳过无效条目 - 压缩比定义为
float64(f.UncompressedSize64) / float64(f.CompressedSize64)，结果 >1 表示有压缩效果 - 对文本类文件（如
.go、.json）通常压缩比在 2–5 倍；二进制资源（如.png）可能接近 1.0，甚至略小于 1（因 ZIP 元数据开销）
处理非 ZIP 格式（如 TAR.GZ）需换用 archive/tar + gzip
archive/zip 无法解析 .tar.gz 或 .tgz——它们是两层封装：先 gzip 解压，再用 archive/tar 解包。要统计压缩比，得分别获取原始未压缩 TAR 流大小（即解压后所有文件总和）和 .gz 文件大小。
- 不能直接从
tar.Header拿“压缩前大小”，因为 TAR 本身不压缩，只是归档；真正压缩发生在 GZIP 层 - 正确做法：用
os.Stat获取.tar.gz文件大小作为“压缩后尺寸”，再遍历tar.Reader累加所有Header.Size作为“压缩前尺寸” - 如果文件是
.tar.zst，就得换成github.com/klauspost/compress/zstd，标准库不支持 Zstandard - 注意：GZIP 可能含多个流（罕见），但常见单文件
.tar.gz只有一个
避免误把加密 ZIP 当普通 ZIP 处理
如果 ZIP 文件启用了传统加密（ZipCrypto）或 AES 加密，archive/zip 仍能读取 FileHeader，但 Open 会返回 zip.ErrFormat 或解压失败。此时 UncompressedSize64 和 CompressedSize64 虽可读，但压缩比无意义——因为内容被加密混淆，压缩率统计失效。
立即学习“go语言免费学习笔记（深入）”；
- 检测方法：检查
f.IsEncrypted()（Go 1.19+ 支持），若为true应跳过该条目并记录警告 - 即使没调用
f.Open()，加密 ZIP 的CompressedSize64可能包含加密头额外字节，导致比值失真 - 不要尝试用密码强行解密来统计——这违背“只统计，不解压”的初衷，也引入额外依赖和安全风险
输出精度与边界情况处理
压缩比是浮点数，但直接打印 %.2f 容易掩盖极端值。比如一个 1KB 文件被压缩成 1025B（膨胀），比值为 0.97；而另一个 1MB 文件压缩成 10KB，比值是 100——两者都该被识别为异常模式。
- 建议分类输出：
标记为“膨胀”，<code>>= 0.98 && 标记为“基本无压缩”，其余为“有效压缩” - 对
UncompressedSize64 == 0的空文件（如占位.gitkeep），压缩比按 0 计算，避免 NaN - 最终汇总时，别只算平均值——中位数更能反映典型文件表现，尤其当 ZIP 中混入一个超大未压缩视频时，平均值会被拉偏
最易被忽略的是 ZIP 中的“数据描述符（data descriptor）”标志位——它可能导致 CompressedSize64 在文件末尾而非头部，而 Go 标准库已自动处理，但如果你自己解析 ZIP 结构，这点必须校验。
