压缩比本质是原始数据字节长度与压缩后完整字节流长度的比值，需确保同数据、同算法、同参数，且gzip/zlib必须调用close()才能获取真实长度。
压缩比计算的本质是字节长度对比
压缩比不是 Go 标准库直接提供的指标，它只是 len(original) 除以 len(compressed) 的比值。关键在于：你得先拿到原始数据和对应压缩后的字节流长度，且必须确保两者是同一份数据、同一压缩算法、同一参数配置下的结果。常见误区是拿文件系统大小（含元数据、对齐填充）或未关闭的 bytes.Buffer 当前长度来算——这会导致比值失真。
用 gzip 或 zlib 做标准压缩时怎么取真实压缩后长度
Go 的 compress/gzip 和 compress/zlib 都需要显式调用 Close() 才会刷新并写入尾部校验和与长度信息。如果只写完就取 buf.Len()，结果会偏小（缺 footer），压缩比虚高。
- 必须在
gzip.Writer/zlib.Writer写入全部数据后调用w.Close() - 推荐用
bytes.Buffer接收压缩输出，buf.Bytes()或buf.Len()才反映完整压缩流长度 - 示例片段：
var buf bytes.Buffer gw := gzip.NewWriter(&buf) gw.Write([]byte("hello world")) gw.Close() // 必须！否则 buf.Len() 不包含 gzip footer ratio := float64(len("hello world")) / float64(buf.Len())
不同压缩级别对压缩比的影响不可忽略
gzip.NewWriterLevel 和 zlib.NewWriterLevel 支持从 gzip.NoCompression 到 gzip.BestCompression（-1 到 -5）。同一输入在 BestSpeed 下可能几乎不压缩，而 BestCompression 下可能多压掉 30% 字节——但耗时可能翻 10 倍。线上服务若只测默认级别（DefaultCompression），上线后切到 BestCompression 就可能触发超时。
- 压缩比接口应把
level作为必传参数，避免隐式依赖默认值 - 测试时至少覆盖
BestSpeed、DefaultCompression、BestCompression三档 - 注意：
zlib的 level 范围是 0–9，而gzip是 -1–-5，传错会 panic
边界情况：空输入、超长输入、不可压缩数据的处理
空字符串压缩后不是 0 字节（gzip header 至少 10 字节），而全零数据或随机噪声可能越压越大。这些都会让压缩比 >1（即“负收益”），但这是正常现象，接口不应报错或拒绝。
- 空输入：
len("") == 0→ 分母非零，但比值为 0，需允许返回0.0 - 不可压缩数据：比如加密后的二进制，压缩后变大是预期行为，比值可能为
0.85 - 超长输入：避免一次性加载到内存；如需流式计算，可改用
io.Pipe+ 两个 goroutine 分别读原始流、写压缩流并统计长度
BestCompression。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
