Go gzip.Reader 怎样读取多成员压缩流

Go 的 compress/gzip 支持把多个连续的 gzip 成员放在同一条输入流中。默认情况下，gzip.Reader 会把这些成员当成一个逻辑数据流，读取结果就是各成员解压内容的拼接；如果业务需要分别处理每个成员，就要关闭多成员模式，并在每个成员结束后调用 Reset。

技术依据：https://pkg.go.dev/compress/gzip#Reader.Multistream

只想拿到合并后的正文时保留默认设置；需要成员名称、成员校验或后续非 gzip 数据的边界时，使用 Multistream(false) 配合 Reset。

一、默认模式会把多个 gzip 成员合并读取

gzip 文件可以由多个独立成员串接而成，每个成员都有自己的头部和尾部。gzip.NewReader 创建的 Reader 默认开启多成员读取，因此调用一次 io.ReadAll 时，后续成员也会继续被解压，最终得到拼接后的字节。

package main

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

func main() {
	var compressed bytes.Buffer
	writeMember(&compressed, "第一段日志\n")
	writeMember(&compressed, "第二段日志\n")

	reader, err := gzip.NewReader(bytes.NewReader(compressed.Bytes()))
	if err != nil {
		log.Fatal(err)
	}
	defer reader.Close()

	// 默认 Multistream 为 true，多个成员会被解压并拼接。
	data, err := io.ReadAll(reader)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Printf("%s", data)
}

func writeMember(dst *bytes.Buffer, text string) {
	writer := gzip.NewWriter(dst)
	// 每次 Close 都写出一个完整的 gzip 成员，便于演示串接输入。
	if _, err := writer.Write([]byte(text)); err != nil {
		panic(err)
	}
	if err := writer.Close(); err != nil {
		panic(err)
	}
}

这个模式适合日志归档、批量传输等“只关心解压后的整体内容”的场景。要注意，Reader 只保留第一个成员的头部字段；如果每个成员的 Name、Comment 或 ModTime 都有业务意义，就不能只做一次整体读取。

二、Multistream(false) 会在当前成员结束处返回 EOF

调用 reader.Multistream(false) 后，Reader 不会自动寻找下一个 gzip 头。当前成员的解压数据读完时，Read 返回 io.EOF，这次 EOF 表示“当前成员结束”，不一定表示整条底层输入已经结束。

func readOneMember(src io.Reader) ([]byte, error) {
	reader, err := gzip.NewReader(src)
	if err != nil {
		return nil, err
	}
	defer reader.Close()

	// 关闭自动跨成员读取，让 EOF 对应当前成员边界。
	reader.Multistream(false)
	data, err := io.ReadAll(reader)
	if err != nil {
		return nil, err
	}
	return data, nil
}

关闭多成员模式的价值在于“停住”：后续字节不会被当前 Reader 吃掉，调用方可以决定是读取下一个成员，还是把剩余内容交给别的解析器。前提是底层读取器实现了 io.ByteReader，这样 gzip Reader 才能在成员边界后保持准确位置。

三、用 Reset 循环逐个读取成员

如果需要逐成员处理，推荐复用同一个 gzip.Reader。每轮先关闭多成员模式，读取当前成员，再调用 Reset 让 Reader 解析下一段 gzip 数据。最后一次 Reset 返回 io.EOF，表示没有下一个成员，这是正常结束条件。

func readMembers(src *bytes.Reader) error {
	reader, err := gzip.NewReader(src)
	if err != nil {
		return err
	}
	defer reader.Close()

	for {
		// 每一轮都明确关闭多成员模式，保证本轮只处理一个成员。
		reader.Multistream(false)
		member, err := io.ReadAll(reader)
		if err != nil {
			return fmt.Errorf("读取成员 %q 失败: %w", reader.Name, err)
		}
		fmt.Printf("成员=%q 内容=%q\n", reader.Name, member)

		// Reset 会从当前底层位置寻找下一个 gzip 成员。
		err = reader.Reset(src)
		if errors.Is(err, io.EOF) {
			return nil
		}
		if err != nil {
			return fmt.Errorf("打开下一个成员失败: %w", err)
		}
	}
}

上面的示例需要补充 errors、fmt、io 和 compress/gzip 导入。bytes.Reader 同时提供读取和按字节读取能力，适合演示成员边界；网络流或自定义 Reader 则要确认是否实现了 ReadByte。

四、把 EOF、校验错误和底层读取器分开处理

io.EOF 与 gzip 校验错误的含义不同。当前成员读到结尾后得到 io.EOF，可以进入下一轮；如果成员的长度或 CRC 校验不对，Read 可能返回 gzip.ErrChecksum，这时不能把已经读出的字节当作完整成员提交。

另外，Close 不会关闭底层 Reader；它也不能替代读到 EOF。需要让 gzip 校验真正完成时，应持续读取到结束，再根据读取错误决定是否接受数据。

五、按需求选择合并读取还是逐成员读取

可以用下面的判断快速选择 API 组合：

一句话总结：Multistream 决定 Reader 是否自动跨过成员边界，Reset 决定调用方何时开始解析下一个成员。默认模式更简单，逐成员模式更适合协议解析、归档索引和带元数据的批处理。

相关问题

• 为什么一次 gzip.NewReader 能读出多个文件的内容？ 因为多成员读取默认开启，连续 gzip 成员会被视为一条逻辑流。
• 关闭 Multistream 后为什么还要调用 Reset？ 当前 Reader 在一个成员结束后不会自动找下一个成员，Reset 用来从当前位置重新解析下一段头部。
• Reset 返回 io.EOF 是错误吗？ 如果当前成员已经完整读完，Reset 返回 io.EOF 表示底层没有后续成员，通常是正常结束。
• 为什么自定义 Reader 会导致后续数据位置不准？ gzip 在需要精确停在成员边界时依赖底层的 io.ByteReader 能力，只有普通 Read 的封装可能预读过多。