压缩比本质是原始字节长度与压缩后字节长度的比值，需手动计算float64(originalSize)/float64(compressedSize)，常见错误包括误用buf.Cap()代替buf.Len()及忽略压缩头开销导致比值失真。
压缩比计算的本质是字节长度对比
压缩比不是某个 Go 标准库函数直接返回的值，而是你手动计算的比值：float64(originalSize) / float64(compressedSize)。关键在于准确获取原始数据和压缩后数据的字节长度，而不是依赖第三方库“自动算好”。很多初学者误以为 compress/gzip 或 compress/zstd 会附带压缩比字段，其实不会。
常见错误现象：compressedSize 取的是缓冲区容量（buf.Cap()）而非实际写入长度（buf.Len()），导致分母偏大、压缩比虚低；或对空字符串、极短文本做压缩，因压缩头开销反而使 compressedSize > originalSize，此时压缩比
- 始终用
buf.Len()获取真实压缩后字节数 - 原始数据长度用
len([]byte(data))或int64(len(data))（若data是字符串） - 压缩前先检查输入是否为空，避免除零 panic
用 gzip.Writer 计算压缩比的最小可行示例
Go 标准库 compress/gzip 最常用，但要注意它默认启用压缩头和校验和——这些元数据会增加几字节，对小数据影响显著。下面是最简可靠写法：
func CalcGzipRatio(data string) (float64, error) {
var buf bytes.Buffer
gz, err := gzip.NewWriterLevel(&buf, gzip.BestSpeed) // 避免 BestCompression 延迟高
if err != nil {
return 0, err
}
_, err = gz.Write([]byte(data))
if err != nil {
return 0, err
}
gz.Close() // 必须调用，否则尾部未 flush，buf.Len() 不准
orig := int64(len(data))
comp := int64(buf.Len())
if comp == 0 {
return 0, errors.New("compressed size is zero")
}
return float64(orig) / float64(comp), nil
}
注意：gzip.NewWriterLevel 的第二个参数影响速度/压缩率权衡，BestSpeed 更适合频繁计算场景；gz.Close() 不可省略，否则 buf.Len() 缺失 gzip 尾部（如 CRC 和 ISIZE 字段）。
立即学习“go语言免费学习笔记（深入）”；
zstd 和 snappy 的压缩比差异与选型建议
如果你需要更高压缩率或更快解压，github.com/klauspost/compress/zstd 和 github.com/golang/snappy 是主流选择，但它们的“压缩比”行为不同：
-
zstd.Encoder默认启用帧头、校验、字典支持，压缩比通常比 gzip 高 5–15%，但初始化开销大；用zstd.WithEncoderLevel(zstd.SpeedFastest)可提速 -
snappy.Encode是无损、极速、固定块压缩，不支持流式，且压缩比通常低于 gzip（尤其对文本），但Encode(dst, src)返回值就是压缩后字节数，无需Close()—— 这点和 gzip 不同 - 性能影响：zstd 单次压缩耗时约是 gzip 的 1.5–2 倍，snappy 是 gzip 的 1/3；但 zstd 解压更快，snappy 解压最快
简单判断：日志归档类场景选 zstd；实时通信 payload 压缩选 snappy；兼容性优先（如需浏览器解压）仍用 gzip。
处理边界情况：空输入、超长数据、并发安全
生产环境容易忽略三点：一是空字符串或 nil 输入导致除零或 panic；二是单次压缩几百 MB 数据时，bytes.Buffer 可能触发多次内存重分配，影响稳定性；三是模块被多 goroutine 并发调用时，若复用 gzip.Writer 实例会 panic（非并发安全）。
- 空输入统一返回
1.0（未压缩）或显式错误，不要让调用方自己判断 - 超长数据改用
io.Pipe+ 分块写入，或预估大小后用bytes.NewBuffer(make([]byte, 0, estimatedSize))减少 realloc - 并发场景下，每次计算都新建
gzip.Writer或使用sync.Pool复用，但必须确保Close()后重置状态
最易被忽略的是：gzip/zstd 的压缩率高度依赖数据熵值。同一段 JSON，结构化程度高时压缩比可达 4.0+；随机字节或已压缩过的图片 base64，压缩比可能只有 0.95。别把压缩比数字当绝对指标，要结合业务数据分布看趋势。
