必须调用 gzip.Writer.Close() 才能确保压缩流完整写入，否则文件损坏；解压时需用 gzip.NewReader 并 defer gr.Close()，配合 io.ReadAll 读完全部数据；压缩级别优先选 DefaultCompression，大文件须流式处理防 OOM。
gzip.Writer 压缩文件时为什么生成的 .gz 文件打不开？
常见错误是没调用 Close() —— gzip.Writer 内部有缓冲，不 Close() 就直接退出，压缩流没刷完，生成的文件损坏，系统或 gunzip 会报 invalid compressed data--format violated。
- 必须在写入全部内容后调用
w.Close()，不能只靠 defer（除非你确定 defer 在所有写操作之后） - 别用
io.Copy(w, src)后就不管了；io.Copy不会自动关w - 如果压缩失败（比如磁盘满），
w.Close()会返回 error，得检查
// 正确示例
f, _ := os.Create("data.txt.gz")
defer f.Close()
w := gzip.NewWriter(f)
_, _ = w.Write([]byte("hello world"))
_ = w.Close() // 关键：必须显式调用
解压时用 gzip.Reader 读不到完整内容？
典型表现：只读出前几个字节，后续数据丢失。根本原因是没把 gzip.Reader 包在 io.ReadCloser 里统一管理，或者忘了读到 io.EOF。
-
gzip.NewReader(r)返回的是*gzip.Reader，它本身不是io.ReadCloser，不带Close()方法；但底层Read可能依赖原始io.Reader的状态 - 如果源是
*os.File，解压完记得file.Close()；否则文件句柄泄漏，且下次打开可能因未关闭而失败 - 别用
bufio.Scanner直接扫gzip.Reader，它默认 64KB 缓冲，可能截断大文件；改用io.ReadAll()或循环Read()
f, _ := os.Open("data.txt.gz")
defer f.Close()
gr, _ := gzip.NewReader(f)
defer gr.Close() // 这个 Close() 是必须的：释放内部资源
data, _ := io.ReadAll(gr) // 读完为止
压缩级别怎么设才合理？
gzip.NewWriterLevel 支持 gzip.NoCompression 到 gzip.BestCompression，但默认 gzip.DefaultCompression（其实是 6）已经很均衡；盲目调高反而容易踩坑。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
gzip.BestCompression（9）压缩率高，但 CPU 占用翻倍，小文件几乎没收益 -
gzip.BestSpeed（1）适合日志实时压缩等低延迟场景，但压缩率可能只有默认的一半 - 如果目标是兼容性（比如给其他语言解压），避免用非标准级别——某些旧版 Python
gzip模块对 level=0（no compression）支持不稳定
w, _ := gzip.NewWriterLevel(output, gzip.BestSpeed) // 实时日志可选 // 或 w, _ := gzip.NewWriterLevel(output, gzip.DefaultCompression) // 大多数场景推荐
处理大文件时内存暴涨甚至 OOM？
核心问题在于一次性 io.ReadAll() 或 bytes.Buffer 把整个解压结果载入内存。Golang 的 gzip 包本身不缓存全文，但上层用法错了就会爆。
立即学习“go语言免费学习笔记（深入）”；
- 永远优先用流式处理：压缩时从
*os.File→gzip.Writer→ 输出文件；解压时反向，中间不落地全量 byte slice - 如果必须转成字符串，确认文件大小可控（比如 io.ReadAll()；否则用
io.Copy(dst, gr)直接写到磁盘或网络连接 - 注意
gzip.Reader的MultiStream字段默认为 false；如果源文件含多个连续 gzip 流（少见），需手动设为 true，否则第二段开始读失败
真正麻烦的不是 gzip 本身，而是忘记「流」这个前提——它设计就是边读边压/解，硬要当“加载器”用，八成会卡在内存或 IO 上。
