Go语言怎么比较不同文本的压缩率-Golang-PHP中文网

压缩率需手动计算：压缩后字节长度 ÷ 原文字节长度；必须统一原文、压缩级别、writer复用方式及调用close()，短文本需综合redis解压开销、网络与cpu成本评估。

go语言怎么比较不同文本的压缩率

用 `compress/gzip` 和 `compress/zstd` 分别压再比长度

压缩率不是靠猜，是算出来的：压缩后字节长度 ÷ 原文字节长度。Go 里没有现成的「比压缩率」函数，得自己写小段逻辑跑一遍。重点不是选哪个库，而是确保每次测量条件一致——同一份原文、同一压缩级别、同一 writer 复用方式（或全新实例）、都调用了 Close()。

短文本（gzip：header + trailer 至少占 18 字节，32B 的 JSON 压完可能变成 50B，压缩率为 156%
zstd 对小数据更友好，启用 zstd.SpeedFastest 时，256B 输入通常能压到 120–140B，且耗时比 gzip 低 40%
别直接拿 bytes.Buffer.Len() 当压缩后长度——必须在 gz.Close() 或 zstdEnc.Close() 后读，否则 buffer 里只是原始输入或不完整流
测试时用 strings.Repeat("a", n) 构造高冗余文本，再用真实 JSON/XML 片段交叉验证，避免被随机字符串误导

`gzip.NewWriterLevel` 和 `zstd.NewWriter` 的级别差异

gzip 的压缩级别是整数 0–9，zstd 是预设常量（如 zstd.SpeedDefault），二者不能数值对等。比如 gzip.BestCompression（=9）和 zstd.SpeedBestCompression 虽都标“最佳”，但 zstd 在 9 级下 CPU 耗时可能翻倍而体积只少 2%，实际没必要。

Go语言（Golang）1.26.0

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

下载

公平对比建议：gzip 用 gzip.BestSpeed（=1） vs zstd 用 zstd.SpeedFastest；gzip 用 gzip.DefaultCompression（=6） vs zstd 用 zstd.SpeedDefault
zstd 的 WithNoEntropy 可关掉 CRC 校验，对可信链路（如进程内通信）能省 12 字节开销，gzip 没对应开关
flate（DEFLATE 底层）可作为第三参照：它没 header，适合嵌入式协议，但 Go 里要自己补校验逻辑

为什么测出来 `gzip` 有时比原文还大？

这不是 bug，是格式特性。gzip 流必须包含 10 字节 header + 8 字节 trailer（CRC32 + uncompressed size），哪怕只压一个空字符串，最小合法输出也是约 20 字节。所以对 len(s) ≤ 32 的字符串，gzip 几乎必然膨胀。

实测：32B 随机字符串经 gzip.BestCompression 压缩后为 58B；同样内容用 zstd.SpeedFastest 是 46B；用 snappy.Encode 是 42B
JSON 尤其容易踩坑：{"id":"xxx"} 这种短结构，不压缩反而更省；但 {"logs":[{...},{...},...]} 这类带重复字段名的数组，压缩率立刻跳到 40%+
别信「默认就该开压缩」——先采样线上真实 payload 长度分布，再决定阈值（例如只对 len > 512 的 string 压缩）

别漏掉 Redis 场景下的隐性成本

往 Redis 存字符串时，压缩决策不能只看「本地压完多小」，还得算上服务端解压开销、网络传输时间、以及客户端 CPU 是否扛得住高频压缩。LZ4 在 Redis 6.0+ 里需配全 compress-depth、compress-threads、compress-algorithm 三项才生效，光改算法没用。