在 Go 语言中进行内存级 gzip 压缩与解压时，有一个容易被忽略但却极易踩坑的技术细节：
简而言之——gzip.Writer 必须显式调用 Close()。若不执行此步骤，压缩后的数据会不完整，解压时必然引发错误。
先给出核心判断：很多开发者习惯使用 defer gw.Close()，但在 gzip 压缩的场景下，这种方式反而容易埋下隐患。因为 defer 会在函数返回前才执行，若在调用 defer 之前就执行了 buff.Bytes()，得到的字节流将缺少 gzip 尾部——即那至关重要的 8 个字节（包含 CRC32 校验和以及原始数据长度）。
当后续通过 gzip.NewReader 解析时，发现尾部缺失，便会直接提示 unexpected EOF。
这个问题看似微小，排查起来却颇为耗时，不少新手甚至经验丰富的开发者都曾在此处“翻车”。
下面是一段完整且可直接复用实现的代码示例，包含 Zip 和 UnZip 两个方法：
package main
import (
"bytes"
"compress/gzip"
"fmt"
"io"
)
type File struct {
Name string
Body *bytes.Reader
}
func (f *File) Zip() error {
var buff bytes.Buffer
gw := gzip.NewWriter(&buff)
// 注意：这里不要用 defer gw.Close()
// 因为我们需要在 Close() 之后才能读取完整数据
if _, err := io.Copy(gw, f.Body); err != nil {
return err
}
if err := gw.Close(); err != nil {
return err
}
f.Body = bytes.NewReader(buff.Bytes())
f.Name += ".gz"
return nil
}
func (f *File) UnZip() error {
gr, err := gzip.NewReader(f.Body)
if err != nil {
return fmt.Errorf("failed to create gzip reader: %w", err)
}
defer gr.Close()
var buff bytes.Buffer
if _, err := io.Copy(&buff, gr); err != nil {
return err
}
f.Body = bytes.NewReader(buff.Bytes())
f.Name = f.Name[:len(f.Name)-3]
return nil
}
接着来聊聊几个关键要点：
- gzip.Writer.Close() 这一步骤绝对不能省略。它负责将剩余数据强制刷出（flush），同时把最后 8 字节的 gzip 尾部（CRC32 校验和与未压缩大小）写入缓冲区。一旦缺失，解压端便会直接给出
unexpected EOF错误。 - 在
Zip()方法中应尽量避免使用defer gw.Close()。因为defer的语义是“函数退出时执行”，而你需要在函数退出之前、Close()执行完毕之后才能安全调用buff.Bytes()。若顺序颠倒，得到的数据就是不完整的。 - 采用
io.Copy进行流式写入，比直接使用WriteTo更灵活，也更便于与其他io.Reader组合使用。这是工程实践中更推荐的做法。 - 在
UnZip()方法中，可以放心地使用defer gr.Close()。gzip.Reader内部可能启动 goroutine 来完成解压工作，若不及时关闭会导致资源泄漏。养成随手close的习惯总是没错的。 - 从可逆性角度来看，连续执行
Zip() → UnZip() → Zip()后，原始数据应保持不变。这一特性可以直接用于校验数据的完整性。
说到底，gzip 压缩与解压本身并不复杂，真正容易出问题的往往是那些“看起来没问题”的写法。只要记住一条原则：压缩后显式关闭，解压后及时清理，那么在内存中使用 *bytes.Reader 进行 gzip 循环操作时，基本就不会出错了。
