zlib.NewWriter输出为空是因为其带缓冲，必须显式调用Close()或Flush()才能将压缩数据写入底层io.Writer；仅Write后不关闭会导致数据滞留缓冲区，buf.Bytes()返回空。
zlib.NewWriter 压缩时为什么输出为空或长度为 0？
因为 zlib.NewWriter 返回的写入器是带缓冲的，必须显式调用 Close() 或 Flush() 才会把压缩数据真正写入底层 io.Writer。只写完不关闭，数据还卡在缓冲区里。
常见错误写法：
w := zlib.NewWriter(&buf)
w.Write([]byte("hello")) // 此时 buf 仍为空
正确做法：
- 写完后立刻调用
w.Close()（推荐，同时完成 flush + 释放资源） - 若需多次写入且不希望关闭，用
w.Flush()强制刷出当前缓冲内容 - 不要依赖
defer w.Close()在函数末尾才关——如果中间就拿buf.Bytes()，还是空的
解压时 io.ReadFull 报错 “unexpected EOF” 怎么办？
这通常是因为传给 zlib.NewReader 的数据不完整，或底层 reader 被提前读空。zlib 流有固定头部和校验尾部，缺一不可。
典型场景：
- 从网络连接直接读取压缩数据，但没读够全部字节就传给了
zlib.NewReader - 用
bytes.NewReader(data)但data是被截断的（比如只取了前 100 字节） - 误把 base64 解码后的 []byte 直接当 zlib 流用，而实际原始数据是 gzip 或其他格式
验证方法：打印原始数据前 10 字节，zlib 压缩流开头两个字节通常是 0x78 0x01、0x78 0x9c 或 0x78 0xda（取决于压缩级别），如果不是，大概率不是 zlib 格式。
compress/zlib 和 compress/gzip 的区别能混用吗？
不能。虽然都基于 DEFLATE 算法，但封装格式不同：compress/zlib 加的是 RFC 1950 头尾，compress/gzip 加的是 RFC 1952 头尾（含文件名、时间戳等额外字段）。两者不兼容。
表现就是：
- 用
zlib.NewReader解一个 gzip 文件 → 报zlib: invalid header - 用
gzip.NewReader解一个 zlib 流 → 报gzip: invalid header
如果你拿到的是 HTTP 响应体且 Content-Encoding: deflate，注意：RFC 2616 里这个值实际可能指 zlib 格式（不是 raw DEFLATE），但某些服务端却发 raw，这时得根据响应头 Content-Encoding: deflate + 实际字节判断，必要时 fallback 到 flate.NewReader（raw DEFLATE）。
如何控制 zlib 压缩级别并避免 panic？
zlib.NewWriterLevel 允许指定压缩级别，但传入非法值（如 -2 或 10）会 panic，不是返回 error。
合法级别范围是：
-
zlib.NoCompression（0） -
zlib.BestSpeed（1） -
zlib.BestCompression（9） -
zlib.DefaultCompression（-1）
别硬写数字，用常量。如果级别来自配置或用户输入，务必先校验：
if level < zlib.NoCompression || level > zlib.BestCompression {
level = zlib.DefaultCompression
}
w, err := zlib.NewWriterLevel(dst, level) // 此时不会 panic
另外，zlib.DefaultCompression 不等于 6 —— 它是 Go 运行时定义的内部默认值（目前是 6），但语义上代表“标准权衡”，不应假设其具体数值。
