Go语言中字节读取器(bytes.Reader)的gzip压缩与解压缩正确实现方法

在 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 循环操作时，基本就不会出错了。