Go gzip 读取多成员文件为什么结果不同

Go 的 gzip.Reader 默认启用 Multistream，会把连续 gzip 成员的解压内容合并返回；调用 Multistream(false) 后，读取在当前成员结束时停止。因此，同一份输入出现“全部内容”和“只有第一段”的差异，可能只是读取策略不同，不一定是解压算法错误。

官方文档：https://pkg.go.dev/compress/gzip#Reader.Multistream。

把差异缩小到成员边界

假设两个数据片段分别压缩后，被拼接成一份输入。面对这种需求，我会先问调用方要的是连续文本，还是每段独立内容。前者可以采用默认行为；后者必须保留成员边界。这是需求判断，不是已经发生的故障复盘。

不太直观的一点是：一个 gzip 文件不必只有一个成员。RFC 1952 把文件描述为成员序列，各成员具有自身头部、压缩数据和尾部。它不是 ZIP 那样的条目目录，默认解压也不会自动创建多个文件。格式说明：https://www.rfc-editor.org/rfc/rfc1952。

对我来说，先让一个最小程序只改变 Multistream 设置，比混用不同命令行工具更容易判断差异来自哪里。

准备两个完整成员的内存样本

示例用同一个 bytes.Buffer 接收两个分别关闭的 gzip.Writer。每个 Writer 的 Close 完成各自成员尾部；仅 Flush 不能代替结束成员。为了便于观察，内容采用 north\n 与 south\n，没有借用官方示例数据。

读取时，合并模式与分段模式各使用新建的 bytes.Reader，从同一份数据的开头开始。否则先读取的分支会改变底层位置，比较便失去了共同起点。

在一个小程序里比较两种读取策略

使用 Go 1.20 或更新版本，保存为 main.go。代码全部在内存中完成，不访问网络，不读取或覆盖已有文件；errors.Join 用于把主要错误与关闭错误一起返回。

package main

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

func sample() ([]byte, error) {
    var dst bytes.Buffer
    for _, text := range []string{"north\n", "south\n"} {
        // 每段创建独立 Writer，Close 后才形成完整 gzip 成员。
        w := gzip.NewWriter(&dst)
        if _, err := w.Write([]byte(text)); err != nil {
            return nil, errors.Join(err, w.Close())
        }
        if err := w.Close(); err != nil {
            return nil, err
        }
    }
    return dst.Bytes(), nil
}

func decode(data []byte, split bool) (parts []string, err error) {
    // bytes.Reader 同时提供 Read 与 ReadByte，保留成员后的准确位置。
    src := bytes.NewReader(data)
    z, err := gzip.NewReader(src)
    if err != nil {
        return nil, err
    }
    defer func() {
        err = errors.Join(err, z.Close())
    }()

    if !split {
        // 不设置开关，采用默认多成员合并行为。
        b, readErr := io.ReadAll(z)
        if readErr != nil {
            return nil, readErr
        }
        return []string{string(b)}, nil
    }

    for {
        // Reset 会恢复默认行为，因此每个成员都重新关闭自动合并。
        z.Multistream(false)
        b, readErr := io.ReadAll(z)
        if readErr != nil {
            return nil, readErr
        }
        parts = append(parts, string(b))

        // 复用同一个底层 Reader，不重新从原始数据开头读取。
        resetErr := z.Reset(src)
        if resetErr == io.EOF {
            return parts, nil
        }
        if resetErr != nil {
            return nil, resetErr
        }
    }
}

func run() error {
    data, err := sample()
    if err != nil {
        return fmt.Errorf("构造样本: %w", err)
    }
    merged, err := decode(data, false)
    if err != nil {
        return fmt.Errorf("合并读取: %w", err)
    }
    separate, err := decode(data, true)
    if err != nil {
        return fmt.Errorf("分段读取: %w", err)
    }
    fmt.Printf("默认模式: %q\n", merged)
    fmt.Printf("分段模式: %q\n", separate)
    return nil
}

func main() {
    // 在 run 的资源收尾完成后处理错误。
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

# 在保存 main.go 的独立目录执行内存示例。
go run main.go

按代码语义，默认模式得到一个字符串元素，内容是两段原文拼接；分段模式得到两个字符串元素。这里给的是读者可复现的预期，没有执行该程序，也没有生成终端截图。

Reset 和底层 Reader 决定边界能否保留

单成员模式并不是“解压一次后自动准备下一段”。当前成员读完后，需要用 Reset 让 gzip.Reader 读取下一个头部。官方实现会在 Reset 中把 multistream 恢复为 true，所以代码在每轮读取前都执行 Multistream(false)。实现地址：https://go.dev/src/compress/gzip/gunzip.go。

另一个容易忽略的条件是底层 io.ByteReader。只有满足这个条件，单成员模式才能把底层位置留在 gzip 成员之后。若输入仅支持 Read，内部可能读取超过当前成员所需的字节；不能再直接从未经共享的外层 Reader 继续解析后续数据。

真实文件可包装成一个 bufio.Reader，再让 gzip 和后续解析共同使用这同一个缓冲 Reader。不要读完后丢弃缓冲层、改回裸文件，也不要在循环中对整个原始字节重新 NewReader，否则可能回到第一段。

接入真实文件时保留错误和资源责任

我会把默认模式用于“只要完整拼接原文”的接口，把单成员模式用于需要逐段处理的格式。分段读取增加了边界管理责任：必须检查每段读取错误和 Reset 错误，不能把损坏头部或截断数据误当成正常结束。

Reader.Close 不关闭底层文件；调用方仍负责关闭它。成员的长度与校验和检查依赖读取到结束，提前 Close 不能代替完整消费。示例检查 io.ReadAll 的错误，失败时不把已返回的部分内容当作成功结果。用于不受信任的大输入时，还应另外设计解压量限制，不能把本例的小规模 ReadAll 直接当成生产容量方案。

这个小项目不需要部署服务或清理临时文件。集成时保留“输入是合法成员序列”这个前提；如果外层格式在 gzip 后混有其他数据，应由外层协议决定接下来解析什么，而不是盲目 Reset 到输入彻底耗尽。

Multistream(false) 会改变压缩文件吗？

不会。它改变当前 Reader 的读取行为，不重写输入，也不改变压缩内容。

只读第一段，是否说明第二段损坏？

不能这样判断。单成员模式主动在当前成员处停止，第二段可能尚未被检查。要读取下一成员，需继续 Reset 并处理错误。

默认模式会为每个成员更新 Header 吗？

不要把合并模式当成逐成员头部枚举接口。默认读取中 Reader 字段保留第一成员头部；需要逐段头部时，在单成员模式下于 NewReader 或成功 Reset 后读取该成员信息，再消费正文。