压缩比必须用原始字节数除以压缩后字节数计算，不可依赖文档描述；需确保原始长度为未压缩的[]byte实际长度，压缩后长度须在gz.close()后取buf.bytes()长度，且压缩级别（gzip.bestspeed至bestcompression）对结果影响显著。
压缩比计算必须基于原始与压缩后字节长度
压缩比不是库自动报告的指标，得自己算：用原始数据长度除以压缩后字节切片长度。别信文档里“高压缩比”的模糊描述，实测才是唯一依据。
常见错误是直接对比字符串长度和 buf.Len()，但要注意：[]byte("中文") 长度是 UTF-8 编码字节数，不是 rune 数；如果原始数据含二进制内容（比如图片头、序列化结构），更要确保用 len(rawData) 而非 len(str)。
- 原始长度必须是未压缩前的
[]byte实际字节数 - 压缩后长度取自底层缓冲区，如
buf.Bytes()的长度，不是gzip.Writer自身大小 - 必须调用
gz.Close()后再取长度，否则尾部校验未写入，结果偏小且不可解压
不同压缩级别对压缩比影响极显著
gzip.SetLevel() 是唯一可控的压缩比调节入口，数值从 gzip.BestSpeed（1）到 gzip.BestCompression（9），默认是 gzip.DefaultCompression（-1）。同一段日志文本，在 1 和 9 级下压缩比可能相差 2.3 倍以上。
- 级别 1：适合实时 HTTP 响应，压缩比常为 1.8–2.5x，CPU 占用最低
- 级别 6：平衡点，多数场景推荐，压缩比约 3.0–3.8x
- 级别 9：适合离线归档，压缩比可达 4.2–5.0x，但耗时可能增加 5–8 倍
- 级别 -1（Default）行为等价于 6，但语义更清晰，建议优先用
gzip.DefaultCompression
运行环境配置真正影响压缩比的只有三处
Go 本身不依赖外部环境变量控制压缩行为，所谓“配置”其实是代码中可显式设置的三个关键点：压缩器复用、缓冲区预分配、初始窗口大小。其他如 GOMAXPROCS、GC 策略只间接影响吞吐，不改变压缩比本身。
- 复用
*gzip.Writer实例能避免重复初始化哈希表和 Huffman 树，但需注意它不是并发安全的——多个 goroutine 写同一个 writer 会 panic - 给
bytes.Buffer预分配容量（buf.Grow(4096)）可减少内存重分配次数，对压缩比无影响，但能稳定 benchmark 结果 - 标准库不暴露 DEFLATE 滑动窗口大小参数（默认 32KB），若真需调整，得换用第三方
github.com/klauspost/compress中的flate.Writer并传入flate.AdvancedEncoder配置
别在生产环境硬编码压缩级别
把 gzip.BestCompression 直接写死在 HTTP middleware 里，等于主动拒绝高并发请求。真实服务中应按请求路径或内容类型动态分级：API JSON 响应用 level 1，后台导出 CSV 用 level 6，冷备日志上传用 level 9。
最容易被忽略的是：gzip 不压缩小数据。HTTP 中若响应体小于 1KB，很多反向代理（如 Nginx）或客户端会跳过解压，此时你算出来的压缩比毫无意义——实际链路根本没走压缩流程。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
