压缩比准确算法为原始字节数除以压缩后字节数，须用len()直接读取原始切片和Close()后最终输出长度；gzip未Close时buf.Bytes()无效，小数据（<512B）易因header/trailer开销导致负优化。
压缩比怎么算才准确
压缩比 = 原始字节数 / 压缩后字节数，但必须用 len() 直接读取原始切片和最终压缩输出的长度，不能依赖中间 buffer 的 Bytes() 或未 Close() 的状态。常见错误是调用 gz.Write() 后直接取 buf.Bytes()，此时拿到的往往是未压缩数据或空切片——因为 gzip.Writer 是缓冲写入，没 Close() 就不会真正压缩并写入 trailer。
什么值才算“达标”
没有统一阈值，得看数据类型和大小：
- 纯文本（JSON、日志）在 4KB+ 时，
gzip.DefaultCompression通常能到 3.0–4.5:1；低于 1KB 很可能 1（变大），这时就不该压 - 已编码内容（如 base64 图片、加密密文、protobuf 序列化结果）基本压不动，压缩比常为 0.95–1.05，属于负优化
- 阈值建议设在 512–2048 字节之间：小于下限跳过压缩，大于上限再计算比值；别对小数据硬压
怎么在代码里自动判断
别手算比值再 if 判断。直接封装逻辑：先测长度，再决定是否走压缩路径。示例关键片段：
func compressIfWorth(data []byte) ([]byte, bool) {
if len(data) < 1024 {
return data, false
}
var buf bytes.Buffer
gz := gzip.NewWriter(&buf)
gz.Write(data)
gz.Close() // 必须
compressed := buf.Bytes()
if len(compressed) >= len(data)*0.9 {
return data, false // 压缩后体积没减少 10% 以上，视为不达标
}
return compressed, true
}
注意：这里用 len(compressed) >= len(data)*0.9 而不是固定比值，是因为小数据误差大，相对阈值更稳。
立即学习“go语言免费学习笔记（深入）”；
容易被忽略的干扰项
gzip header 和 trailer 固定占约 18–20 字节，对短数据影响极大。比如 200 字节的 JSON，压缩后可能变成 215 字节——看似“压了”，实则白忙。zstd 在这类场景更靠谱，但它的 header 默认也带 12 字节开销，若用 zstd.WithNoEntropy 可去掉 CRC，得手动权衡校验需求。
