准确获取压缩前后字节长度需：先将原始数据转为[]byte，用bytes.Buffer接收压缩输出，调用w.Close()后取buf.Bytes()得真实压缩长度，再计算1-float64(len(compressed))/float64(len(original))。
压缩前后的字节长度怎么准确获取
Go 语言里没有内置的「压缩率」计算函数，得自己算：1 - float64(len(compressed)) / float64(len(original))。关键在 len() 的输入必须是原始字节切片和压缩后的真实字节切片，不是字符串或接口类型——尤其注意 gzip.Writer 或 zlib.Writer 写完后必须调用 Close()，否则内部缓冲区没刷新，Bytes() 返回的长度偏小。
常见错误是直接对 strings.NewReader("...") 压缩后拿 io.ReadAll()，但漏了 w.Close()，导致压缩率虚高（比如显示 90%，实际只有 70%）。
- 原始数据统一转成
[]byte再传入压缩器，避免 UTF-8 编码差异干扰字节计数 - 使用
bytes.Buffer接收压缩输出，调用buf.Bytes()获取最终字节切片 - 对空字符串或极短内容（如
"a"），gzip 可能因头部开销反而更大，压缩率会是负值，需单独判断
gzip、zlib、zstd 在压缩率统计中的行为差异
不同压缩算法的 header 和 block 结构不同，直接影响小数据场景下的统计结果。比如 gzip 固定 10 字节 header + 可选 extra 字段；zlib 是 2 字节 header + 4 字节 Adler32 校验；zstd（需第三方库如 github.com/klauspost/compress/zstd）header 更紧凑，但默认启用 dictionary 时需确保统计时禁用，否则结果不可复现。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
gzip.NewWriterLevel(buf, gzip.BestCompression)显式指定级别，避免默认DefaultCompression导致跨环境结果不一致 - zlib 不支持 level 设置（Go 标准库
compress/zlib只有BestSpeed和BestCompression两个常量，且底层固定为 level 6） - 若对比多种算法，原始数据必须完全相同（
bytes.Equal()验证），且每次新建 writer 实例，不能复用
如何避免 ioutil.ReadAll 导致的内存误判
ioutil.ReadAll（或 io.ReadAll）本身没问题，但容易让人忽略：它读的是 writer 输出流，而该流可能包含未 flush 的缓冲数据。更隐蔽的问题是，如果用 io.MultiWriter 同时写到文件和 buffer，buffer 里混入了其他日志或分隔符，压缩率就完全失真。
正确做法是绕过流式读取，直接从 bytes.Buffer 提取：
var buf bytes.Buffer w := gzip.NewWriter(&buf) w.Write(data) w.Close() // 必须！ compressed := buf.Bytes() // 这才是真实压缩后字节
- 别用
io.Copy(w, bytes.NewReader(data))后直接buf.Bytes()——Copy不触发Close()，header 尾部校验字段缺失 - 如果数据来自
http.Request.Body等不可重放源，先io.ReadAll到[]byte，再压缩，避免多次读取失败 - 统计时记录
len(data)和len(compressed)即可，不需要解压验证——除非你怀疑压缩器异常（比如返回空 slice）
并发统计压缩率时的资源泄漏风险
每个 gzip.Writer 或 zlib.Writer 内部持有缓冲区，高频创建/关闭易触发 GC 压力；更危险的是，若忘记 Close()，writer 持有的 hash/adler32 状态不会释放，长期运行可能缓慢增长内存占用。
建议方案：
- 用
sync.Pool复用*gzip.Writer，但注意 pool 中对象必须重置内部 buffer 和状态（w.Reset(io.Writer)），不能直接复用未 close 的实例 - 对单次请求级统计（如 HTTP 中间件），用局部变量 + 显式
Close()最安全，比 pool 更可控 - 避免在 defer 中写
w.Close()后继续用buf.Bytes()—— defer 执行时机不确定，buf 可能已被回收（虽少见，但 race detector 会报）
压缩率本身是个简单比值，但 Go 里每一步 IO 和生命周期管理都可能悄悄扭曲结果。最常被忽略的是 writer 关闭时机和原始数据编码一致性——这两点错一点，统计值就失去横向比较意义。
