compress/flate包不提供压缩率计算，需手动用原始字节长度除以压缩后长度；注意调用w.close()、用len([]byte(s))而非len(s)，压缩率>1.0属正常，且压缩率不反映cpu或并发安全。
compress/flate 包本身不提供压缩率计算功能，它只负责压缩和解压。压缩率必须由你手动算：用原始长度除以压缩后长度。但直接套公式容易翻车——尤其对短字符串，压缩后反而更大。
为什么直接 len(compressed) / len(original) 会误导？
DEFLATE 流没有头部长度字段，flate.Writer 输出的是裸压缩流（RFC 1951），不含任何元数据长度标识。所以你拿到的 buf.Bytes() 就是纯压缩字节，可以直接比长度，但要注意：
- 漏掉
w.Close()→buf.Bytes()缺失最后缓冲块，压缩率虚高 - 原始数据是字符串？必须用
len([]byte(s))，不是len(s)（后者是 rune 数，对含中文/emoji 的字符串完全错误） - 压缩率 > 1.0 表示“越压越大”，这非常正常，
flate对
怎么安全地测一次压缩率？
核心是确保流程完整、类型一致、边界清晰。下面这段代码能复用在日志采样或配置下发前的预判中：
func calcFlateRatio(src string) (float64, error) {
var buf bytes.Buffer
w, err := flate.NewWriter(&buf, flate.BestSpeed)
if err != nil {
return 0, err
}
_, err = w.Write([]byte(src)) // 注意：必须转 []byte
if err != nil {
w.Close()
return 0, err
}
err = w.Close() // 必须关！否则 buf 里没写完
if err != nil {
return 0, err
}
rawLen := len([]byte(src))
compLen := buf.Len()
if compLen == 0 {
return 0, errors.New("compressed output is empty")
}
return float64(rawLen) / float64(compLen), nil
}
调用时：ratio, _ := calcFlateRatio("hello world") —— 如果返回 0.85，说明压后体积是原来的 85%，实际变大了。
什么情况下压缩率数字有意义？
压缩率只有在数据量足够、用途明确时才值得看：
- HTTP 响应体压缩：关注 1KB~1MB 区间，
flate.BestSpeed下结构化 JSON 通常有 2.5–4x 压缩率 - 日志行压缩：单行 if len(src)
- 对比不同 level：对同一段 >50KB 的 protobuf，
flate.BestCompression可能比DefaultCompression多压出 8–12%，但 CPU 时间翻倍 - 别拿它和
gzip比：gzip 在 DEFLATE 外还包了 18 字节头部+尾部 CRC，压缩率数值天然略低，但兼容性好
最容易被忽略的精度陷阱
压缩率不是性能指标，而是空间收益快照。它不反映 CPU 开销、内存峰值或并发安全。比如你复用一个 flate.Writer 实例去压 100 个字符串，即使每次 Reset(io.Writer)，只要没串行控制，就可能触发 fatal error: concurrent write to non-safe map —— 此时你看到的压缩率数字毫无意义，进程已经崩了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
