压缩比正确公式是(原始字节数−压缩后字节数)/原始字节数，结果转为百分比；须close压缩器再取长度，避免缓冲未刷新，多算法对比需统一用空间节省比例并固定参数。
压缩比计算的正确公式是什么
压缩比不是简单用原始大小除以压缩后大小，而是 (原始字节数 - 压缩后字节数) / 原始字节数，结果通常转为百分比。很多初学者误用 原始 / 压缩（比如得到 5.2 表示“压缩了 5.2 倍”），这在统计场景下会误导后续分析——尤其当你要横向对比 gzip、zstd、snappy 等不同算法时，统一用「空间节省比例」才可比。
Go 标准库不直接提供压缩比函数，必须手动读取源数据长度和压缩流结束后的实际写入长度。
用 gzip 做统计时怎么避免常见陷阱
最常踩的坑是：用 bytes.Buffer 写入压缩流后，直接调用 buf.Len() —— 这没问题；但若中间用了 bufio.Writer 或提前 Close() 不充分，就可能漏掉 flush 缓存，导致长度偏小。
- 务必在
gzip.Writer.Close()后再取长度，否则底层 buffer 可能未完全写出 - 不要复用
gzip.Writer实例做多次压缩统计，它内部状态不可重置，应每次新建 - 原始数据建议用
len(src)而非io.ReadAll后再取长度，避免重复读或内存放大
src := []byte("hello world...") // 实际中可能是读文件或网络 body
var buf bytes.Buffer
gw := gzip.NewWriter(&buf)
gw.Write(src)
gw.Close() // 关键：必须 close 才能确保所有压缩数据落进 buf
ratio := float64(len(src)-buf.Len()) / float64(len(src)) * 100
批量统计多个文件时如何控制内存和精度
对大量小文件做压缩比统计，如果每个都全量读入内存再压缩，容易 OOM；而逐块流式压缩又难以精确获取原始总长（尤其非 seekable 的 reader）。折中方案是分两阶段：
- 第一阶段：用
os.Stat().Size()获取原始文件大小（快且准） - 第二阶段：用
os.Open+io.Pipe或带缓冲的io.Copy流式压缩，同时用io.MultiWriter把压缩输出同时写到hash.Hash和计数器，避免存完整压缩体 - 注意：某些压缩算法（如
zstd）支持WithEncoderLevel，不同 level 会影响压缩比，统计时必须固定 level 并记录配置项
想对比 zstd 和 gzip 怎么组织代码结构
别写两套几乎一样的逻辑。用接口抽象压缩行为，把算法差异收进工厂函数：
type Compressor interface {
Compress([]byte) (compressed []byte, size int, err error)
}
func NewGzipCompressor() Compressor { ... }
func NewZstdCompressor(level int) Compressor { ... }
这样主统计循环只关心输入/输出长度，不耦合具体实现。额外提醒：zstd 的第三方库（如 github.com/klauspost/compress/zstd）默认启用并发，若你压的是单个小 buffer，反而因 goroutine 开销降低效率，建议显式设 WithEncoderConcurrency(1)。
真正难的不是算出一个数字，而是确保每次测量条件一致：相同输入、相同缓冲策略、相同关闭时机、相同算法参数——这些细节稍有偏差，压缩比波动可能超过 5%，比算法本身差异还大。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
