如何使用Go语言计算二进制数据压缩比-Golang-PHP中文网

压缩比为原始文件大小与压缩后文件大小的比值，即“压缩前字节数:压缩后字节数”，需确保两者均为未编码的原始二进制长度，不可使用base64或hex等编码格式参与计算。

如何使用go语言计算二进制数据压缩比

压缩比计算公式必须明确原始与压缩后字节长度

压缩比不是 Go 标准库直接提供的指标，而是你自己用两个 len([]byte) 相除得出的比值。关键在于：原始数据必须是未编码的二进制切片（比如从文件读出的 []byte），压缩后也必须是原始压缩格式（如 zlib 或 gzip 输出的 []byte），不能是 Base64 编码或 hex 字符串——否则长度失真，算出来完全没意义。

常见错误是拿 JSON 字符串去压，或者把 gzip.NewReader 的输出误当作压缩数据；实际上你要的是 gzip.Write 后得到的底层 buffer 内容长度。

用 `compress/gzip` 压缩并获取真实压缩后长度

Go 的 compress/gzip 默认写入 io.Writer，不直接返回 []byte。要拿到压缩后字节长度，得用 bytes.Buffer 接住输出：

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

var buf bytes.Buffer
gw := gzip.NewWriter(&buf)
gw.Write(originalData) // originalData 是 []byte
gw.Close() // 必须调用，否则数据可能未 flush
compressedLen := buf.Len()

gw.Close() 不可省略——它会写入 gzip 尾部校验和和长度信息，缺了会导致压缩不完整、解压失败，且 buf.Len() 偏小
别用 gw.Flush() 替代 Close()，它不写尾部，压缩流不合法
如果原始数据极小（如空切片或几个字节），gzip 可能因 header 开销反而更大，此时压缩比 > 1.0 是正常现象

不同压缩器对同一数据结果差异很大

compress/zlib、compress/flate、compress/zstd（需第三方）对同一段二进制数据产出的长度不同，直接影响压缩比数值。例如：

zlib 默认使用 DEFLATE，header 比 gzip 略小，适合嵌入式或协议头紧凑场景
gzip 多 18 字节固定 header + trailer，但兼容性最好
zstd 在中高阶压缩级别下通常比 gzip 小 10–20%，但 Go 官方不内置，需引入 github.com/klauspost/compress/zstd
压缩级别设置（如 gzip.BestSpeed vs gzip.BestCompression）会显著影响 buf.Len()，务必在业务场景中固定级别再比对

注意内存分配与边界情况

计算压缩比本身很快，但实际压缩过程会分配新内存。如果你反复计算大量小数据块的压缩比（比如日志采样），要注意：

避免每次新建 bytes.Buffer——可复用并调用 buf.Reset()
原始数据为 nil 时，len(nil) 是 0，但 gzip.Write(nil) 不 panic，压缩后长度仍为合法值（约 20 字节），需按需处理零长输入逻辑
若原始数据含大量重复零字节，某些压缩器（如 flate）可能触发特殊优化，而随机加密数据则几乎无法压缩——压缩比接近 1.0 是预期行为，不是 bug

真正容易被忽略的是：你拿去压缩的“原始数据”是否已带某种编码或冗余结构。比如 protobuf 序列化后的二进制本身已有一定压缩倾向，而 base64 编码后再压只会更差——确认输入形态，比选哪个库更重要。