gzip.Writer无法实时获取压缩比，需用io.MultiWriter配合计数器统计原始字节数，并让gzip.Writer写入bytes.Buffer以获取压缩后字节数，复用同一实例并适时Flush才能保证统计准确。
gzip.Writer 压缩时无法直接获取实时压缩比
Go 标准库的 gzip.Writer 不暴露已写入原始字节数和压缩后字节数，所以你调用 Write() 时根本拿不到“当前压缩了多少、压缩率多少”——它只管把数据喂进 DEFLATE 流，等 Close() 才刷出尾部校验。想边压边算比，得自己套一层统计逻辑。
用 io.MultiWriter + 计数器手动统计原始与压缩字节数
核心思路是：把原始数据先写进一个计数器（io.Writer），再同时写进 gzip.Writer；压缩流的目标则接一个带长度统计的 bytes.Buffer 或自定义 io.Writer。这样就能在每次 Write() 后立刻算出当前累计压缩比。
- 原始数据字节数：用
io.MultiWriter包裹一个空的io.Discard和一个自定义计数器（比如counter{}实现Write(p []byte)并累加len(p)） - 压缩后字节数：让
gzip.Writer写入一个bytes.Buffer，每次写完调用buf.Len() - 注意：不要在循环中反复
gzip.NewWriter(buf)—— 每次新建会重置压缩上下文，导致压缩比失真；应复用同一个*gzip.Writer实例
zstd 库支持更细粒度的流式状态观测
github.com/klauspost/compress/zstd 的 Encoder 提供了 EncodedSize() 方法（需启用 WithEncoderLevel(zstd.SpeedDefault) 及以上），但该值是估算值；更可靠的是用 zstd.Encoder 的 Write() 返回值（实际写入底层 io.Writer 的字节数），配合你自己的输入计数器同步更新。它的优势在于：压缩上下文稳定、支持并发编码、且 Write() 调用返回值可信赖（不像某些 gzip 封装会因缓冲策略返回 0）。
- 别依赖
EncodedSize()做精确比值，它只是基于滑动窗口的预测 - 真实压缩比 = 累计输入字节数 / 累计
zstd.Encoder.Write()返回的总字节数 - 如果用
zstd.NewWriterLevel创建流，记得显式调用Flush()（不是Close()）来推动当前批次压缩输出，否则bytes.Buffer.Len()不会增长
实时显示的常见陷阱
压缩比数字跳变剧烈、首几KB显示“100%”或负值，基本都是统计时机错位导致的。关键点不在算法本身，而在你何时读取、是否复用实例、以及是否混淆了“已提交压缩”和“已落盘字节”。
立即学习“go语言免费学习笔记（深入）”；
- 不要在
gzip.Writer.Close()之后才开始统计——那时已经晚了，且无法做到“实时” - 避免用
bufio.Writer套在gzip.Writer外层再统计，这会引入二级缓冲，Write()返回值不再对应压缩后真实字节数 - 小块数据（如单行日志）反复压缩会导致负增益（压缩后反而更大），此时压缩比可能 >100%，这是正常现象，不代表代码错了
