gzip.Reader 处理多成员压缩流的读取方案

如果一个压缩输入由多个 gzip 成员连续拼接而成，Go 的 gzip.Reader 默认会把它们解压成一段连续内容。这个默认行为适合“把分片压缩数据还原成一个逻辑文件”的场景；如果每个成员代表一份独立日志或一条带元数据的记录，就要关闭多成员自动合并，逐个读取并在成员之间调用 Reset。

需要合并内容时直接使用默认模式并读到 io.EOF；需要保留成员边界时调用 Multistream(false)，消费当前成员后用 Reset 进入下一个成员。读取结束前不要把已经返回的数据当作最终可信结果，因为 gzip 的长度和校验和要到成员尾部才确认。

官方资料：https://pkg.go.dev/compress/gzip

先判断：你要的是合并内容还是成员边界

gzip 文件可以是多个独立 gzip 流的串联，每个成员都有自己的头部、压缩数据和尾部。gzip.Reader 的 Header 只记录当前读取对象的头信息；默认连续读取时，后续成员的头不会单独暴露出来。

因此可以先用下面的判断表确定实现方向：

默认模式会把多个成员合并解压

gzip.NewReader 创建后，多成员支持默认开启。只要持续读取，Reader 会自动识别下一个 gzip 头，把各成员的未压缩数据按输入顺序拼接。对调用方来说，这和“一个 gzip 包含所有内容”很接近。

package main

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

func readMerged(r io.Reader) ([]byte, error) {
	// NewReader 只负责解压；底层 r 不会由 gzip.Reader.Close 关闭。
	zr, err := gzip.NewReader(r)
	if err != nil {
		return nil, fmt.Errorf("创建 gzip reader: %w", err)
	}
	defer zr.Close()

	// 读取到 EOF 才能让 gzip.Reader 检查当前成员的长度和校验和。
	data, err := io.ReadAll(zr)
	if err != nil {
		return nil, fmt.Errorf("读取 gzip 内容: %w", err)
	}
	return data, nil
}

func main() {
	// 示例只展示调用关系；实际输入可以替换为 os.File 或网络请求体。
	data, err := readMerged(strings.NewReader("不是 gzip 数据，仅用于展示函数签名"))
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println(len(data))
}

这个模式有两个容易忽略的点。第一，io.ReadAll 返回错误时不能只保留已经读出的部分；官方文档要求把到达 io.EOF 之前返回的数据视为暂定结果。第二，gzip.Reader.Close 不会关闭底层文件或请求体，外层资源仍要由创建它的一方负责关闭。

需要独立处理时关闭 Multistream

当成员边界有业务含义时，调用 zr.Multistream(false)。此时当前成员读完后，Read 返回 io.EOF，但底层 Reader 仍停在当前 gzip 成员之后，接下来可以调用 Reset 读取下一个成员。

下面的示例把每个成员当成独立记录处理，并读取当前成员的文件名：

package main

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

func readMembers(input *bytes.Reader) error {
	// bytes.Reader 实现 io.ByteReader，关闭多成员后能准确停在成员边界。
	zr, err := gzip.NewReader(input)
	if err != nil {
		return fmt.Errorf("读取第一个成员: %w", err)
	}
	defer zr.Close()

	for member := 1; ; member++ {
		// 每次 Reset 后重新声明逐成员模式，避免依赖隐含状态。
		zr.Multistream(false)
		payload, err := io.ReadAll(zr)
		if err != nil {
			return fmt.Errorf("读取第 %d 个成员: %w", member, err)
		}

		// Header 属于当前成员；在 Reset 之前读取并保存需要的字段。
		fmt.Printf("member=%d name=%q bytes=%d\n", member, zr.Name, len(payload))

		// Reset 返回 io.EOF 表示底层已经没有下一个 gzip 成员。
		err = zr.Reset(input)
		if errors.Is(err, io.EOF) {
			return nil
		}
		if err != nil {
			return fmt.Errorf("切换到第 %d 个成员: %w", member+1, err)
		}
	}
}

循环的顺序很重要：先设置 Multistream(false)，再完整读取当前成员；读取成功后保存 Header 中需要的字段，最后才 Reset。如果在 io.ReadAll 返回前就把当前成员当作完成，校验和错误可能被漏掉。

三个症状能帮助定位读取问题

只得到第一个成员

通常是代码调用了 Multistream(false)，但没有在当前成员结束后执行 Reset。如果业务本来就需要合并内容，可以删除这次关闭多成员的调用，或者改用默认模式。

第二个成员的头信息读不到

默认模式会直接把后续成员的数据拼到输出，Header 不会为每个成员建立历史记录。要读取每个成员的 Name、Comment 等字段，必须逐成员读取，并在下一次 Reset 前保存当前 Header。

读取结果看起来完整，但最后报校验错误

不要忽略 io.ReadAll、io.Copy 或循环中的读取错误。gzip 的长度与校验和在成员尾部确认，错误可能出现在已经收到部分数据之后；这时应丢弃或隔离不完整结果，而不是继续把它当作可靠文件。

底层 Reader 和资源责任要一起处理

逐成员模式依赖底层 Reader 的位置可控。官方文档要求底层输入实现 io.ByteReader，这样 gzip.Reader 才能在当前成员结束后准确停在下一个字节位置。bytes.Reader、bufio.Reader 等常见类型满足这个条件；如果输入只实现普通 io.Reader，解压器可能提前读取更多数据，后续格式解析就不能假定位置精确。

资源责任也要分开：gzip.Reader.Close 只关闭解压器自身，不关闭底层 Reader；如果底层是文件、HTTP 响应体或压缩归档的打开句柄，仍要由外层用 defer 关闭。创建 Reader 失败时没有可关闭的 gzip 对象，但底层资源依然要按原有生命周期处理。

最后按数据契约选择实现

可以把选择压缩成四条规则：

• 只关心最终解压文本或字节流：使用默认多成员模式，持续读取到 io.EOF。
• 每个成员有独立文件名、时间或业务编号：使用 Multistream(false)，读取后保存 Header，再 Reset。
• gzip 后面还有别的协议数据：底层输入必须支持 io.ByteReader，并避免让 gzip.Reader 自动跨过成员边界。
• 无论哪种模式：都检查构造、读取、Reset 和 Close 的错误，不能把部分读取结果当成完整结果。

多成员 gzip 并不是另一套压缩格式，真正的差别在于“成员边界是否属于业务数据”。先做这个判断，再选择默认合并或逐成员读取，代码会比事后猜测 EOF 的含义更稳定。

相关问题

gzip.Reader.Close 会关闭文件吗？不会，它只关闭 gzip 解压器；文件或请求体要由外层代码关闭。

为什么逐成员读取一定要读到 EOF？成员尾部包含未压缩长度和校验和，只有消费到尾部才能发现损坏。

Reset 是重新分配一个 Reader 吗？不是，它会丢弃当前 Reader 状态并复用对象读取新的输入，适合连续处理成员。