压缩比需采样估算而非直接计算，应通过io.MultiWriter+ByteCounter在写入前分流统计原始字节，避免阻塞；zstd比gzip更优，支持block模式与CRC校验，且对日志格式变化更鲁棒。
压缩比不是直接算出来的，是采样估算的
Go 语言本身不提供「实时压缩比」的内置指标，gzip 或 zstd 等压缩器只输出压缩后字节流，不自动回传原始/压缩长度比。你得自己在流式处理中插桩统计——但不能对每条日志都记原始长度（吞吐暴跌），必须用采样或滑动窗口估算。
典型错误是：在 io.Pipe 或 bufio.Writer 后直接读取 len(data) 和 len(compressed) 做除法，这会阻塞流、破坏实时性，还漏掉 header/trailer 开销。
- 只对固定周期（如每秒）或固定数量（如每 1000 条）的日志做全量长度采集
- 用
hash/fnv对日志前 64 字节哈希后取模决定是否采样，避免偏斜 - 压缩器启用
gzip.BestSpeed或zstd.WithEncoderLevel(zstd.SpeedFastest)，否则压缩耗时会掩盖采样开销
用 io.MultiWriter + 计数器拦截原始字节流
最轻量的方式是在写入压缩器前，把原始数据同时写进一个计数器 io.Writer，而不是事后解析 buffer。Go 标准库的 io.MultiWriter 能干这事，且零分配（只要计数器 Writer 实现了 Write([]byte) 并只累加长度）。
type ByteCounter struct{ N int64 }
func (c *ByteCounter) Write(p []byte) (int, error) {
c.N += int64(len(p))
return len(p), nil
}
// 使用示例：
origCounter := &ByteCounter{}
compCounter := &ByteCounter{}
gw := gzip.NewWriter(io.MultiWriter(compWriter, compCounter))
io.Copy(gw, io.MultiReader(origReader, origCounter)) // ❌ 错！MultiReader 不适合流式日志
// 正确做法：在日志逐条写入前分流
注意：io.MultiReader 不适用于持续追加的日志流（比如 tail -f 场景），它是一次性读完。真实场景应改用自定义 io.Writer，在 Write() 中同步更新两个计数器。
立即学习“go语言免费学习笔记（深入）”；
zstd 比 gzip 更适合高吞吐日志流
实测中，zstd 在 1–10 MB/s 日志写入速率下，压缩比通常比 gzip 高 8%–15%，且 CPU 占用低 30% 以上。关键是它的压缩器支持「独立 block 模式」，可让每条日志单独压缩并附带长度头，方便后续精确计算单条压缩比（用于异常检测）。
- 用
zstd.Encoder替代gzip.Writer，设置zstd.WithEncoderCRC(true)防止损坏误判 - 避免全局复用同一个
*zstd.Encoder实例——并发写入会 panic；用sync.Pool管理实例 - 压缩比波动大时（比如日志突然变空或全数字），检查是否启用了
zstd.WithEncoderSingleSegment(true)，它会禁用 block 分割，导致小日志压缩率骤降
压缩比突降往往不是算法问题，而是日志格式漂移
线上观察到压缩比从 4.2x 掉到 1.3x？大概率不是压缩器坏了，而是日志内容变了：新增了大量 UUID、base64 编码字段、或时间戳精度从秒升到纳秒——这些都严重削弱字典复用效果。
验证方法很简单：抽样 1MB 原始日志，用 zstd -v -T1 和 gzip -v 分别压，对比输出的「ratio」字段。如果两者都崩，说明是数据问题；只有 gzip 崩而 zstd 稳，说明 gzip 的 LZ77 窗口跟不上新格式的重复模式。
真正容易被忽略的是：日志行尾的 \r\n 混用（Windows vs Linux）、编码从 UTF-8 变成 GBK、甚至某服务悄悄开了 JSON pretty-print——这些都会让压缩器「看不见」本可复用的字符串前缀。
