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() 后立刻算出当前累计压缩比。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

• 原始数据字节数：用 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%”或负值，基本都是统计时机错位导致的。关键点不在算法本身，而在你何时读取、是否复用实例、以及是否混淆了“已提交压缩”和“已落盘字节”。

• 不要在 gzip.Writer.Close() 之后才开始统计——那时已经晚了，且无法做到“实时”
• 避免用 bufio.Writer 套在 gzip.Writer 外层再统计，这会引入二级缓冲，Write() 返回值不再对应压缩后真实字节数
• 小块数据（如单行日志）反复压缩会导致负增益（压缩后反而更大），此时压缩比可能 >100%，这是正常现象，不代表代码错了

真正难的不是算两个数的比值，而是确保这两个数来自同一压缩上下文、同一生命周期、且不被缓冲层截断或延迟。一旦混用不同层级的 Writer 或忽略 Flush 语义，显示出来的数字就只是幻觉。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！