gzip.Writer无法直接获取压缩比，因其内部采用流式DEFLATE压缩，仅在Close()时完成编码，Write()数据先入缓冲区且不暴露原始字节数，须手动统计输入与压缩后字节数。
Go语言标准库的gzip.Writer不提供实时压缩比接口，必须自己统计原始输入字节数和压缩后输出字节数才能算出比值——这不是调用某个方法就能拿到的数字，而是要你控制写入路径、复用实例、并在合适时机读取长度。
为什么gzip.Writer无法直接获取压缩比
gzip.Writer内部使用DEFLATE流式压缩，它只在Close()时刷新尾部校验和并完成最终编码。调用Write()时，数据先进入内部缓冲区，未必立刻产生压缩输出；bytes.Buffer.Len()在未Flush()或Close()前不会反映真实压缩体积。更关键的是，它根本不暴露已处理原始字节数——这个值你得自己记。
用io.MultiWriter + bytes.Buffer手动统计
核心是把同一份原始数据同时送进两个地方：一个计数器（统计输入）、一个gzip.Writer（压缩后写入bytes.Buffer）。
- 原始字节数：用自定义
counter结构体实现Write(p []byte)，每次累加len(p) - 压缩后字节数：让
gzip.Writer写入bytes.Buffer，每次写完后调用buf.Len() - 必须复用同一个
*gzip.Writer实例，不能在循环里反复gzip.NewWriter(buf)——否则压缩上下文重置，首块压缩比会严重失真 - 需要显式调用
gz.Flush()（不是Close()）来推动当前批次压缩输出，否则buf.Len()不变
用zstd替代可简化统计逻辑
第三方zstd库（如github.com/klauspost/compress/zstd）的Encoder在Write()时就返回实际写入底层io.Writer的字节数，比gzip更可靠：
立即学习“go语言免费学习笔记（深入）”；
-
zstd.Encoder.Write()返回值是真实压缩后字节数，可直接累加 - 配合你自己的输入计数器，每轮都能算出瞬时比：
float64(totalIn) / float64(totalCompressed) - 避免
gzip中因缓冲策略导致Write()返回0、但数据其实还在内部队列的问题 - 注意：别依赖
EncodedSize()，它是滑动窗口估算值，不是实测输出长度
压缩比跳变剧烈或出现负值的常见原因
这基本不是算法问题，而是统计时机错位：
- 在
gzip.Writer.Close()之后才读buf.Len()——此时只能拿到最终结果，不是“实时” - 把
bufio.Writer套在gzip.Writer外层再统计——二级缓冲导致Write()返回值不等于压缩后字节数 - 对极小块数据（如单行日志）反复压缩——DEFLATE头开销占比过大，首几KB可能显示“100%”甚至计算出负压缩比
- 没复用
*gzip.Writer，每次新建都丢弃历史上下文，压缩率失去连续性
真正难的不是写代码，是判断哪一时刻的buf.Len()对应哪一段输入——这个边界必须和你的业务分块逻辑对齐，否则数字只是幻觉。
