必须显式调用 gzip.Writer.Close() 才能写出完整压缩流，否则丢失校验和与结束标记导致解压失败；compress/bzip2 不在 go 标准库中，需用第三方库替代。
compress/gzip 读写文件时必须显式关闭 Writer 才能写出完整压缩流
gzip 压缩不是写完数据就立刻落盘，底层会缓冲，不调用 Close() 就会丢失尾部校验和及压缩结束标记，导致解压失败（常见报错：gzip: invalid checksum 或 unexpected EOF）。
- 写文件：先用
gzip.NewWriter()包裹*os.File，写入数据后必须调用w.Close()，不能只用defer w.Close()（若提前 return 可能漏掉） - 读文件：用
gzip.NewReader()包裹*os.File后，读完无需手动关闭底层 file，但应调用gzr.Close()释放资源（尤其在循环处理多个文件时） - 错误示例：
io.copy(w, r)后没w.Close()→ 解压时提示 “not a gzip file”
compress/zlib 和 compress/flate 的层级关系与使用选择
compress/zlib 是 zlib 格式封装，底层复用 compress/flate；compress/flate 是纯 deflate 算法实现（无头尾格式），不能直接用于通用解压工具（如系统 gzip 命令）。
- 需要兼容标准 zlib 工具（如 python
zlib.decompress()、命令行zlib-flate -uncompress）→ 用compress/zlib - 要最小化头部开销或与嵌入式 deflate 流对接 → 用
compress/flate，但注意它不写/读 zlib 头（0x78 0x9c 等），需自行处理协议对齐 -
compress/gzip和compress/zlib都带完整格式头、校验和、长度字段；compress/flate只负责核心压缩逻辑，更底层也更易出错
compress/bzip2 不在 Go 标准库中，别白费劲找 compress/bzip2 包
Go 官方 compress/ 子目录下只有 bzip2 的文档占位符，实际未实现。搜索时看到旧博客提到它，基本是误传或混淆了第三方库。
- 替代方案：用
github.com/klauspost/compress/bzip2（纯 Go，性能好）或golang.org/x/exp/bzip2（实验性，已归档，不推荐） - 如果必须用系统 bzip2：通过
exec.Command("bzip2", "-d")管道调用，但注意安全与路径依赖 - 标准库中唯一支持的非 gzip/zlib 格式是
compress/lzw（主要用于 GIF），但极少单独使用
多级嵌套压缩（如 gzip → gzip）需逐层打开 Reader，且顺序不能颠倒
嵌套压缩不是“自动识别”，Go 不会递归探测格式。比如一个文件先用 gzip 压缩，再用 zlib 压缩，你得按相反顺序解包：zlib.NewReader() → gzip.NewReader()。
立即学习“go语言免费学习笔记（深入）”；
- 错误做法：对双 gzip 文件只套一层
gzip.NewReader()→ 报错gzip: invalid header（因为第二层 gzip 头被第一层解出来当明文读了） - 正确链式写法：
gzip.NewWriter(zlib.NewWriter(file))；对应读法：gzip.NewReader(zlib.NewReader(file)) - 注意内存：每层
NewReader都增加缓冲，嵌套过深（>3 层）可能触发bufio.Scanner: Token too long类错误，建议限制层数或改用流式处理
实际项目里最容易卡住的，是忘记 gzip.Writer.Close() 和误以为 compress/bzip2 存在——这两个点查日志时往往要绕半天。