必须显式调用 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 的文档占位符，实际未实现。搜索时看到旧博客提到它，基本是误传或混淆了第三方库。

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

• 替代方案：用 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 存在——这两个点查日志时往往要绕半天。