Go gzip.Reader.Multistream 为什么会连续读取多个压缩流

如果一个输入由多个独立的 gzip 成员首尾拼接而成，Go 的 gzip.Reader 默认会把它们当成一条连续的解压数据来读取，所以看到“第二段内容也被读出来”并不是 Reader 失控，而是 Multistream(true) 的默认语义。需要按成员区分日志段、文件头或后续格式时，显式调用 Multistream(false)。

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

本文只解决“为什么连续读取”和“怎样逐个成员读取”两个问题。它不讨论压缩级别、压缩率或 gzip 文件损坏修复。

先看清输入：一个文件可能包含多个 gzip 成员

gzip 格式允许多个带各自头部和尾部的压缩成员连续出现。可以把输入想成“成员 A + 成员 B”，而不是一个更大的单体成员。NewReader 先解析第一个成员；当默认的多成员模式打开时，Reader 到达 A 的尾部后会继续识别 B，并把两段解压结果表现成一条连续的字节流。

因此，读取循环里只有一个最终的 io.EOF，并不能据此判断“第一个 gzip 成员已经结束”。如果业务把每个成员当作独立记录，就不能依赖默认行为来切分。

默认 Multistream(true)：适合把拼接内容当成一条流

Multistream(true) 是默认状态。它适合滚动日志合并、分段压缩后再统一解压等场景：调用方只关心所有成员展开后的顺序内容，不需要读取每个成员的名称或边界。

package main

import (
	"compress/gzip"
	"io"
	"log"
	"os"
)

func readAsOneStream(input io.Reader) error {
	// 默认允许 gzip.Reader 跨越成员边界继续读取。
	zr, err := gzip.NewReader(input)
	if err != nil {
		return err
	}
	defer zr.Close() // 关闭 Reader，不替调用方关闭底层 input。

	_, err = io.Copy(os.Stdout, zr)
	return err // 只有读到最终 EOF 后，校验结果才完整。
}

func main() {
	if err := readAsOneStream(os.Stdin); err != nil {
		log.Fatal(err)
	}
}

这里的关键不是 io.Copy，而是没有关闭多成员能力。若第二个成员的校验失败，错误也可能在继续读取时才出现；调用方应把读操作返回的错误当成最终结果处理。

需要逐个成员时：关闭多成员并保留输入位置

逐成员读取要在创建 Reader 后立刻调用 Multistream(false)。此模式下，Reader 在当前成员结束时返回 io.EOF，而不是自动进入下一个成员。为了让底层 Reader 停在成员边界之后，它必须实现 io.ByteReader；常见的 *bufio.Reader 可以满足这一要求。

package main

import (
	"bufio"
	"compress/gzip"
	"io"
)

func readMembers(src io.Reader) error {
	// bufio.Reader 同时提供缓冲与 io.ByteReader 能力。
	br := bufio.NewReader(src)
	zr, err := gzip.NewReader(br)
	if err != nil {
		return err
	}
	defer zr.Close()

	for {
		zr.Multistream(false) // 当前成员结束就返回 EOF，不吞掉下一个成员。
		if _, err := io.Copy(io.Discard, zr); err != nil {
			return err
		}

		// Reset 重新读取 br 中的下一个 gzip 成员；没有成员时返回 io.EOF。
		err = zr.Reset(br)
		if err == io.EOF {
			return nil
		}
		if err != nil {
			return err
		}
	}
}

示例把内容丢弃，只突出成员边界。实际业务可以在每轮复制前读取 zr.Name、zr.Comment 和 zr.ModTime，再把当前成员写入独立缓冲区。注意：Reset 复用 Reader 的状态，但不会替你创建新的底层输入。

常见误区与选择建议

还要区分 Reader.Close 与底层输入的关闭：前者不会关闭传入的 io.Reader。如果底层是文件或网络连接，资源生命周期仍由创建它的代码负责。

相关问题

Multistream(false) 为什么要求 io.ByteReader？

因为 Reader 需要在当前 gzip 成员结束后把底层输入准确停在下一个字节位置，不能因为预读而吞掉后续格式。实现了 io.ByteReader 的缓冲输入能提供这个边界。

没有下一个成员时 Reset 一定返回 EOF 吗？

在底层输入已经位于成员末尾之后的情况下，Reset 会尝试解析下一个成员；没有下一个成员时返回 io.EOF，其它格式或读取错误则应原样处理。

小结：默认多成员模式解决“拼接后当成一条流”的问题；逐成员处理则要主动关闭它，并用支持 io.ByteReader 的底层输入配合 Reset。把这两个模式分开，才能避免把成员边界误判成最终文件边界。