zlib.newwriter 比 gzip.newwriter 更快，因二者同用 flate 压缩算法，但 zlib 省去 gzip 的 10–20 字节头部及 crc32 校验开销，尤其在小包场景下优势明显；协议层面 gzip 兼容性更好，zlib 仅适用于两端可控的内网或自定义协议。
zlib.NewWriter 和 gzip.NewWriter 压缩同一数据，为什么 zlib 更快？
因为 zlib 在 Go 标准库中默认使用更激进的压缩策略（DefaultCompression 对应 level 6），而 gzip.NewWriter 默认用的是 DefaultCompression，但底层调用的是 gzip 协议封装后的 deflate，多了一层头和校验开销。实际压测中，纯 deflate 流（zlib）比 gzip 少约 10–20 字节固定头部 + CRC32 校验计算，对小包或高频流影响明显。
实操建议：
- 如果传输协议自己控制完整性（比如已用 TLS 或额外 SHA256），优先选
zlib.NewWriter，省开销 - 别直接对比
zlib.NewWriter(w)和gzip.NewWriter(w)的Write耗时——要确保都调用Close()或Flush()，否则 zlib 可能缓存未写出 - gzip 兼容性更好（HTTP、curl、nginx 默认识 gzip），zlib 需对方明确支持 raw deflate 或带 zlib header
compress/zlib.Reader 读取 gzip 数据会 panic："zlib: invalid header"
这是典型协议错配。compress/zlib.Reader 期望输入是 RFC 1950 格式（zlib header + deflate stream），而 gzip 是 RFC 1952（magic bytes 1f 8b）。Go 不做自动检测，直接按 zlib 解析，头两个字节对不上就报错。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 用
zlib.NewReader解开 nginx 返回的Content-Encoding: gzip响应体 → panic - HTTP 客户端没设
Accept-Encoding: identity，服务端返回 gzip，代码却用 zlib 解
解决办法只有换 Reader：
- 确认来源是 gzip → 改用
gzip.NewReader - 不确定格式但想兼容 → 先 peek 前两字节：
if b[0] == 0x1f && b[1] == 0x8b→gzip.NewReader，否则zlib.NewReader - 别依赖文件扩展名（如
.gz不一定就是 gzip，有些工具用它存 zlib 流）
设置压缩级别后，zlib 和 gzip 的 CPU/压缩率差异到底有多大？
在 Go 中，zlib.NewWriterLevel 和 gzip.NewWriterLevel 都接受 -2 到 9 的 level 参数，底层共用 flate 包。所以同 level 下，核心压缩算法、字典大小、查找窗口完全一致；差异只来自协议封装成本。
性能影响要点：
- level 0（NoCompression）：zlib 比 gzip 快 ~15%，因无压缩+无 CRC 计算
- level 6（DefaultCompression）：zlib 吞吐高 8–12%，尤其在 4KB 以下小 buffer 场景
- level 9（BestCompression）：两者差距收窄到 3–5%，因为压缩耗时远超协议开销
- 内存占用相同——都用
flate.NewWriter，buffer 大小由参数控制，和外层协议无关
示例：同样压缩 1MB JSON
zw, _ := zlib.NewWriterLevel(&buf, zlib.BestCompression) zw.Write(data) zw.Close() // 必须 close 才写 footer
不调 Close()，zlib 不写 Adler32 校验码，解压端可能拒绝（取决于 reader 实现）。
HTTP 传输中该选 zlib 还是 gzip？
选 gzip。不是因为技术更强，而是生态锁死：所有浏览器、CDN、反向代理（nginx、Cloudflare）、HTTP 库（net/http）默认只识别 Content-Encoding: gzip。你发 zlib 流过去，对方大概率当乱码处理。
除非你控制两端：
- 内网 RPC、自定义协议、gRPC 的
encoding扩展 —— 此时 zlib 是合理选择，省带宽又快 - HTTP 响应头硬写
Content-Encoding: deflate？危险。RFC 2616 说它“may be either zlib or gzip”，实际浏览器基本只认 zlib 格式，但 nginx 等中间件常拦截并转成 gzip，行为不可控 - 真要减头部开销，不如关掉 HTTP compression，改用 protobuf + gzip —— 把压缩逻辑收口到序列化层，更可控
最容易被忽略的一点：Go 的 http.Server 压缩中间件（如 gorilla/handlers.Compression）内部用的是 gzip.NewWriter，你没法替换成 zlib——协议层已经固化了。
