Go compress/gzip 多成员解压的结束标记怎么判断

遇到连续拼接的 gzip 数据时，最容易误判的是“第一次 io.EOF 到底代表什么”。Go 的 compress/gzip 默认开启多成员读取：多个独立 gzip 成员会被当作一个连续输入，直到所有成员都读完才结束。如果业务要逐个记录成员、区分成员边界，或者检查 gzip 后面是否还有自定义数据，就必须主动关闭这个默认行为。

一、默认模式为什么看不到每个成员的结束

gzip 文件并不一定只包含一段压缩流。两个独立的 gzip 成员直接拼接后，标准读取器可以把它们解压成一段连续的明文。gzip.NewReader 创建的读取器默认开启 Multistream(true)，因此下面这类代码的结束点是整个输入的末尾：

zr, err := gzip.NewReader(src)
if err != nil {
    return err
}
defer zr.Close()

// 注释：io.Copy 会持续读取所有连续的 gzip 成员，直到整个输入结束。
if _, err := io.Copy(dst, zr); err != nil {
    return err
}

这适合日志分片、批量压缩后希望得到一份连续文本的场景。这里的 io.EOF 由 io.Copy 消化掉了，调用方只会看到复制成功；即使手写 Read 循环，也不能把第一次成员的结束当成整个文件结束。

二、关闭多成员后，io.EOF 才能表示当前成员完成

如果业务需要逐个统计成员大小、读取每个成员自己的头信息，先在真正读取前关闭自动串接：

zr, err := gzip.NewReader(bufReader)
if err != nil {
    return err
}

// 注释：关闭多成员模式后，当前成员结束时 Read 会返回 io.EOF。
zr.Multistream(false)
if _, err := io.Copy(memberWriter, zr); err != nil {
    return err
}

// 注释：此时只说明一个成员已经读完，不代表底层输入没有下一个成员。
fmt.Println("one gzip member finished")

完整消费很重要。gzip.Reader.Close 不会替你关闭底层文件或网络连接，而且只有读到 io.EOF，gzip 校验和才完成验证。也就是说，提前退出循环后直接 Close，不能把“已读到一半”当作“已验证成功”。

三、Reset 循环如何判断下一个成员和非法尾部

逐成员处理的关键是使用实现了 io.ByteReader 的缓冲读取器。这样读取器可以停在当前 gzip 成员之后，不会因为预读过多而丢失下一个成员的起点。

func readGzipMembers(src io.Reader, handle func(int, io.Reader) error) error {
    // 注释：bufio.Reader 同时满足 io.Reader 和 io.ByteReader，便于精确停在成员边界。
    bufReader := bufio.NewReader(src)
    zr, err := gzip.NewReader(bufReader)
    if err != nil {
        return err
    }
    defer zr.Close()

    for index := 1; ; index++ {
        // 注释：每次 Reset 后都重新关闭多成员串接，确保一次循环只处理一个成员。
        zr.Multistream(false)
        if err := handle(index, zr); err != nil {
            return err
        }

        // 注释：回调必须读到 EOF，Reset 才能判断下一个成员或尾部状态。
        if err := zr.Reset(bufReader); err != nil {
            if errors.Is(err, io.EOF) {
                return nil // 注释：没有下一个 gzip 成员，输入正常结束。
            }
            if errors.Is(err, gzip.ErrHeader) {
                return fmt.Errorf("gzip member %d 后存在非法尾部: %w", index, err)
            }
            return fmt.Errorf("读取下一个 gzip 成员失败: %w", err)
        }
    }
}

func main() {
    // 注释：示例只把每个成员复制到独立缓冲区，生产代码可在回调中解析或落盘。
    err := readGzipMembers(input, func(index int, member io.Reader) error {
        var out bytes.Buffer
        if _, err := io.Copy(&out, member); err != nil {
            return fmt.Errorf("成员 %d 校验失败: %w", index, err)
        }
        fmt.Printf("member=%d bytes=%d\\n", index, out.Len())
        return nil
    })
    if err != nil {
        log.Fatal(err)
    }
}

这里有三个容易混淆的结果：

四、先决定是否需要成员边界，再决定 API 组合

如果只是把多个 gzip 分片解压成一条连续数据流，保留默认多成员模式最简单；如果要逐成员保存、读取每个成员的 Header，或在压缩数据后拼接索引，就用 bufio.Reader + Multistream(false) + Reset。另外，Reset 复用的是同一个读取器状态，不能把它当作关闭底层资源的方法，文件和网络连接仍由调用方负责关闭。

常见问题

只调用一次 Multistream(false) 够吗？

不够。每次成功 Reset 后都应再次调用 Multistream(false)，否则后续读取可能重新进入多成员串接模式。

为什么 Reset 后不是 io.EOF 而是 ErrHeader？

通常表示当前成员后还有字节，但这些字节不是合法 gzip 头。若格式允许自定义尾部，应在协议层明确长度或标记，不能把所有 ErrHeader 都吞掉。

Close 能检查 checksum 吗？

不能替代完整读取。应先持续读取到 EOF，再处理读取错误，最后调用 Close；Close 本身也不会关闭底层 Reader。

判断 gzip 多成员结束标记时，先问清楚“我要的是整段明文的结束，还是某个成员的结束”。默认模式解决前者，关闭多成员并配合 Reset 才能可靠处理后者。