压缩比计算必须在 close() 后进行，因 gzip.writer 缓冲未刷新时 len() 返回不完整结果，解压易失败；正确顺序为 write()→close()→buf.len()；接口应返回 float64 以保精度，分母需校验非零。
压缩比计算必须在 Close() 之后做
压缩比不是写完数据就能算的——gzip.Writer 内部有缓冲，不调用 Close() 就无法确保尾部校验、CRC 和长度信息写入，bytes.Buffer.Len() 返回的只是未刷新的中间结果，可能比真实压缩体小 10–20 字节，解压时直接报 gzip: invalid header。
正确顺序只能是：Write() → Close() → 取 buf.Len()。别试图用 Flush() 替代，gzip.Writer 没有公开的 Flush() 方法，且即使有，也不等价于 Close() 的语义。
- 常见错误：在
defer gz.Close()后立刻读buf.Len()，但 defer 是函数返回时才执行，此时buf.Len()还是 0 - 解压失败时先检查压缩后字节流长度是否 ≥ 18（gzip 最小合法头长度），否则大概率是没
Close() - 如果要反复压缩不同数据，复用
bytes.Buffer时记得调用buf.Reset()，否则旧数据残留会导致压缩体异常增大
压缩比接口应返回 float64 而非 int 或 string
用 int 会丢失精度（比如 3.2 倍压缩比变成 3），用 string 则丧失可比性与下游计算能力。直接返回 float64 最务实，调用方爱四舍五入还是保留三位小数，自己决定。
示例接口定义：
func CompressRatio(src, dst []byte) float64 {
if len(src) == 0 {
return 0 // 或 panic，取决于业务容忍空输入
}
return float64(len(src)) / float64(len(dst))
}
- 注意分母为 0 的 panic 风险：若
dst是空切片（比如压缩失败但没校验 error），除零 panic；务必在调用前确认len(dst) > 0 - 不要把压缩比逻辑塞进
Compressor接口里——它只管Compress()/Decompress()，比值是上层观测行为，不属于策略契约 - 如果需要带单位的可读字符串（如
"3.21x"），另写一个FormatRatio(r float64)辅助函数，别污染核心接口
HTTP 场景下不能直接用响应体字节算压缩比
HTTP 响应开启 gzip 后，实际传输的是 Content-Encoding: gzip + 压缩体，但 Go 的 http.ResponseWriter 是个黑盒 writer，你拿不到原始响应体和压缩后字节的精确对应关系——中间可能穿插 chunked 编码、header 写入、甚至中间件劫持。
真要测 HTTP 压缩比，得在更底层做：
- 用
httptest.ResponseRecorder拦截响应，但它只暴露Body.Bytes()，而该值已是压缩后字节，原始内容已不可见 - 正确做法：在 handler 内提前把待响应数据
Compress()成[]byte，再手动设置Header.Set("Content-Encoding", "gzip")和Write()，这样你同时持有src和dst - 别依赖
Content-Length响应头反推——它可能被中间件重写，也可能压根没设（chunked 场景）
zstd / snappy 等第三方算法的压缩比计算无额外陷阱
只要它们也遵循「输入 → 压缩 → 输出完整字节流」这一模式，压缩比计算逻辑就完全一致。真正要注意的是：不同算法对小数据（
- zstd 默认启用 dictionary 和帧头，50 字节输入可能产出 32 字节输出（比原数据还小），也可能产出 64 字节（含元数据开销）——必须实测，不能假设
- snappy 设计目标就是速度优先，压缩比通常只有 1.5–2.0x，远低于 gzip 的 3–5x，但如果你的场景是微服务间 protobuf 序列化传输，这点开销换来的延迟下降往往更关键
- 所有算法都建议加一层预判：若
len(src) ，直接跳过压缩，避免引入 CPU 开销却无收益
Close() 的 gzip.Writer 输出当真值，然后花半天排查为什么解压失败——其实只是少了 10 个字节的尾部。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
