Go gzip 多段压缩流怎么连续读取

日志归档、分片备份或网络传输中，多个 gzip 成员可能直接首尾拼接在一个字节流里。Go 不需要你先切分文件：gzip.NewReader 创建的 Reader 默认开启多段读取，会把每个成员解压后的内容连续返回。只有当业务需要保留每个成员的文件名、校验边界或单独统计时，才应调用 Multistream(false)，配合 Reset 逐个消费。

只想得到完整文本时直接使用默认的 gzip.Reader；想逐成员处理时关闭多段模式，并在每次读到 io.EOF 后再调用 Reset。不要只依赖 Close 判断校验是否成功。

为什么一个 gzip 文件能包含多个成员

gzip 成员不是只有一段压缩字节，它包含自己的 Header、压缩数据和 Trailer。多个成员可以连续放在同一个 io.Reader 中，每个成员都能独立解压和校验。Go 文档把这种输入称为 concatenation：默认的 Reader 会返回所有成员解压后数据的拼接结果，Reader 结构里只保留第一个成员的 Header 元数据。

这意味着“连续读取”并不是循环创建多个 Reader。对整体消费来说，Reader 会在当前成员结束后继续识别下一个 Header；调用方只需要像使用普通 io.Reader 一样读取。

默认模式：把拼接成员解压成一份数据

下面的小项目先把两段独立 gzip 数据写到同一个缓冲区，再用一次 gzip.NewReader 和 io.Copy 读取。示例重点是写入端每个成员都必须 Close，这样 Trailer 才会落到缓冲区；读取端则让默认的 Multistream 行为接管成员切换。

package main

import (
    "bytes"
    "compress/gzip"
    "fmt"
    "io"
)

func appendMember(dst *bytes.Buffer, text string) error {
    zw := gzip.NewWriter(dst)
    // 每个成员都单独关闭，Close 会写入当前成员的 Trailer。
    if _, err := zw.Write([]byte(text)); err != nil {
        return err
    }
    return zw.Close()
}

func main() {
    var joined bytes.Buffer
    // 两次写入产生两个独立 gzip 成员，但它们共享同一个字节流。
    if err := appendMember(&joined, "第一段日志\n"); err != nil {
        panic(err)
    }
    if err := appendMember(&joined, "第二段日志\n"); err != nil {
        panic(err)
    }

    zr, err := gzip.NewReader(bytes.NewReader(joined.Bytes()))
    if err != nil {
        panic(err)
    }
    // io.Copy 会持续读取，默认 Multistream 会自动跨过下一个成员。
    var plain bytes.Buffer
    if _, err := io.Copy(&plain, zr); err != nil {
        panic(err)
    }
    // 读到 EOF 后再关闭，才能让 gzip 完成末尾校验。
    if err := zr.Close(); err != nil {
        panic(err)
    }
    fmt.Print(plain.String())
}

这个模式适合把分片压缩日志还原成一个顺序输入。需要注意的是，Reader.Read 返回的数据在收到 io.EOF 前都只是暂定结果；如果某个成员的长度或校验和不对，错误可能在接近该成员末尾时才出现。

逐成员读取：用 Multistream(false) 保留边界

如果每个成员代表一份独立文件，就不要让默认模式吞掉边界。设置 zr.Multistream(false) 后，当前成员读完会返回 io.EOF，底层 Reader 会停在这个 gzip 成员之后。随后调用 zr.Reset(reader)，既能复用 Reader，又能让它从当前输入位置尝试读取下一个成员。

func readMembers(input *bytes.Buffer) error {
    zr, err := gzip.NewReader(input)
    if err != nil {
        return err
    }
    defer zr.Close()

    for member := 1; ; member++ {
        // 关闭自动拼接，让本轮只暴露一个 gzip 成员。
        zr.Multistream(false)
        var plain bytes.Buffer
        if _, err := io.Copy(&plain, zr); err != nil {
            // ErrChecksum 说明当前成员内容不能作为可信结果使用。
            return fmt.Errorf("成员 %d 解压失败: %w", member, err)
        }
        fmt.Printf("成员 %d: %s", member, plain.String())

        // Reset 会从底层 reader 的当前位置寻找下一个成员。
        err := zr.Reset(input)
        if err == io.EOF {
            // 没有下一个 Header，整个拼接流已经结束。
            return nil
        }
        if err != nil {
            return fmt.Errorf("读取下一个成员失败: %w", err)
        }
    }
}

bytes.Buffer 实现了 io.ByteReader，所以 gzip Reader 可以在关闭多段模式后把底层位置留在成员边界。若传入的自定义 Reader 只有 Read、没有 ReadByte，NewReader 可能预读更多字节，逐成员模式就不适合直接依赖它定位后续数据。

EOF、校验错误和资源关闭怎么判断

实际项目里可以把逐成员结果写入独立文件、消息或数据库记录，同时保留成员序号与 zr.Name 等 Header 字段。若只需要整体内容，默认模式更短、更不容易把“成员结束”和“整个输入结束”混在一起。

相关问题

gzip.NewReader 会自动读取第二个 gzip 成员吗？

会。Multistream 默认开启，Reader 会把连续成员的解压数据拼接返回。

为什么关闭 gzip.Reader 还不能证明校验成功？

因为 Close 不负责替底层 Reader 读完数据；应先持续读取到 io.EOF，读取过程中的 gzip.ErrChecksum 才能被识别。

逐成员读取时 Reset 为什么可能直接返回 EOF？

这表示当前成员之后没有下一个合法 gzip Header，是正常结束；若返回其他错误，才需要按损坏或截断输入排查。