必须显式捕获原始与压缩后字节数，因 ResponseWriter 不暴露写入长度，gzip.Writer 未 Close() 前缓冲区和 trailer 未写入，buf.Len() 不准；须 gz.Write→gz.Close→取 buf.Len()，并按原始大小分桶上报压缩比。
必须显式捕获原始与压缩后字节数，不能依赖 Content-Length 或响应体长度推算
为什么不能直接读 ResponseWriter 的写入长度
Go 的 http.ResponseWriter 是接口，不暴露已写入字节数；即使包装它，也拦不住底层 gzip.Writer 写入缓冲区前的内部状态。真实压缩比必须在压缩发生时、数据尚未流到网络层之前测量。
- 常见错误：在
WriteHeader后读len(buf.Bytes())—— 此时gzip.Writer可能还没Flush()或Close()，尾部校验和缺失，buf.Len()比实际传输小 - 更隐蔽的问题：用
io.MultiWriter同时写日志和响应体，但没同步gzip.Close()，导致压缩流不完整，解压失败且字节数不准 - HTTP/2 场景下，头部压缩（HPACK）和 body 压缩（gzip）是两层，
Content-Encoding: gzip仅覆盖 body，原始大小指未 gzip 的 body 字节，不是整个帧
gzip.Writer 必须调用 Close() 才能拿到最终字节数
gzip.Writer 内部有缓冲区和 trailer（校验和、CRC 等），不 Close() 就不会写入这些元数据，bytes.Buffer.Len() 返回的是中间状态，压缩比虚高、解压端报 gzip: invalid checksum。
- 正确顺序：
gz.Write()→gz.Flush()（可选，确保当前块写出）→gz.Close()（强制完成并写 trailer）→ 再取buf.Len() - 别用
defer gz.Close()包裹整个 handler——如果 handler panic，defer不执行，指标丢失且响应体损坏 - 示例关键片段：
buf := bytes.Buffer{} gz := gzip.NewWriter(&buf) _, _ = gz.Write(bodyBytes) _ = gz.Close() // 必须 compressedSize := buf.Len() originalSize := len(bodyBytes) ratio := float64(compressedSize) / float64(originalSize)
压缩比指标要和请求上下文绑定，避免采样偏差
单纯记录 “平均压缩比” 没意义：1KB JSON 压完可能膨胀，100KB 日志可能压到 30%，混在一起拉低整体数值，掩盖小数据负优化问题。
立即学习“go语言免费学习笔记（深入）”；
- 按原始大小分桶上报，例如：
compress_ratio_bucket{size="512"}=0.92、compress_ratio_bucket{size="8192"}=0.31 - 记录是否触发压缩：加标签
enabled="true"/enabled="false"，后者对应小数据跳过逻辑（如len(body) ） - 带上
content_type标签，区分application/json和text/plain，前者通常冗余高，后者可能几乎不压 - 避免在中间件里用全局变量存指标——并发写会竞争，改用
prometheus.HistogramVec或带 request ID 的结构体传参
最易被忽略的一点：压缩比指标本身不该参与压缩决策逻辑。比如用上一次的 ratio 动态调 gzip.SetLevel()，会导致反馈震荡——某次压缩慢了就降级，降级后压缩率变差又触发下一轮调整。指标只用于观测和告警，策略开关应基于静态阈值或业务 SLA。
