Go标准库compress包是压缩算法的组织者，不直接提供实现；其子包flate、gzip、zlib、lzw和bzip2分别对应不同格式：flate实现纯DEFLATE流，无头尾；gzip遵循RFC 1952，含header与trailer；zlib依RFC 1950，常用于PNG与HTTP；lzw用于GIF，需指定字节序；bzip2仅支持解压。
compress 是 Go 标准库中专用于数据压缩/解压缩的顶层包，它本身不提供具体算法实现，而是组织了多个子包，每个对应一种压缩格式或底层算法。你用不到 compress 本身，真正要 import 的是它的子包。
flate：纯 DEFLATE 流，不带头尾
这是 RFC 1951 的直接实现，只处理原始压缩字节流，没有 gzip header、zlib wrapper、CRC 或长度字段。
适用场景：
• 和 HTTP 响应体（Content-Encoding: deflate）对接
• 自定义二进制协议中嵌入压缩载荷
• 需要精细控制压缩参数（如 level、dict、no-flush 控制）
⚠️ 常见错误：把 flate 压缩结果当 gzip 文件打开——会失败，因为缺魔数和 trailer。
gzip：标准 .gz 文件与 HTTP gzip 兼容
compress/gzip 封装了 DEFLATE，并严格遵循 RFC 1952，写入 header（含魔数 1f 8b）、压缩数据、trailer（CRC32 + uncompressed length）。
关键点：
• 必须调用 Writer.Close()，否则 trailer 缺失，解压时大概率报 unexpected EOF 或 invalid checksum
• 支持压缩级别（gzip.NoCompression 到 gzip.BestCompression）
• gzip.NewReader 能自动跳过常见 header 变体，对部分省略 trailer 的 HTTP 响应也有一定容错
zlib：RFC 1950 格式，常用于网络协议
和 gzip 类似但 header/trailer 不同（魔数是 78 01 等），常用于 PNG、HTTP（Content-Encoding: zlib）、某些 RPC 协议。
注意：
• 使用 zlib.NewWriterLevelDict 可传入自定义字典，解压端必须用相同字典初始化 zlib.NewReaderDict，否则解压失败
• 字典不是“密码”，而是预加载的重复字符串集合，对小数据或结构化文本提升明显
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
lzw：GIF 兼容字典编码，适合短文本/图像索引
compress/lzw 实现 LZW 算法，最典型用途就是读写 GIF 图像的图层数据。
实操提醒：
• 初始化时需指定 lzw.LSB 或 lzw.MSB 字节序，GIF 用 LSB
• 输入数据太短（比如少于 20 字节）可能压缩后反而变大，LZW 不适合极小 payload
• 解压时若遇到截断数据，Reader.Read 会返回 io.ErrUnexpectedEOF，不是 panic，要主动检查
立即学习“go语言免费学习笔记（深入）”；
compress/bzip2 也在标准库中，但注意：它仅提供解压支持（bzip2.NewReader），**不包含压缩器**——Go 官方从未实现 bzip2 压缩逻辑。别在代码里找 bzip2.NewWriter，它不存在。
真正容易被忽略的是：所有这些包都实现了 io.Reader 和 io.Writer，意味着你能无缝套娃——比如用 gzip.NewWriter 包一层 flate.NewWriter，但通常没必要，因为 gzip 内部已用 flate；更实用的是把它们串进 io.Pipe 或 io.MultiWriter 做日志归档分发。 
