Go compress/gzip.Reader 怎样区分成员流和尾部数据

如果一个输入由“gzip 成员流 + gzip 成员流 + 普通尾部数据”组成，直接使用默认的 gzip.NewReader 很容易把多个成员拼成一个连续的逻辑结果。需要识别成员边界时，应在创建 Reader 后调用 Multistream(false)，每个成员读到结尾会返回 io.EOF，然后再用同一个底层读取器创建或重置下一个 Reader。

官方地址：https://pkg.go.dev/compress/gzip#Reader.Multistream

关键点只有三个：默认模式适合“把多个 gzip 成员合并读取”，关闭多成员模式适合“逐个处理”；底层输入最好实现 io.ByteReader，这样 Reader 才能停在当前成员之后；当前成员的 io.EOF 不是整个输入的结束，还要继续判断后面是下一个 gzip 头还是普通尾部。

默认模式为什么看不出成员边界

gzip.Reader 默认开启多成员读取。它会把连续的独立 gzip 数据流当作一个逻辑输入，前一个成员读完后继续读取下一个成员。对于解压日志、归档文本或普通消息内容，这种行为很方便；但如果每个成员代表一条独立记录、一个分片或一段带元数据的对象，就不能只依赖一次 io.Copy 的结果来判断成员数量。

因此，先把需求分成两类：

• 只要解压后的连续字节：保持默认的 Multistream(true)。
• 要处理成员级元数据，或 gzip 后面还拼接了别的格式：使用 Multistream(false)。

Multistream(false) 如何固定当前成员边界

调用 Multistream(false) 后，当前 Reader 在读完一个 gzip 成员时返回 io.EOF。这次 EOF 表示“当前成员结束”，不是“底层输入已经没有任何字节”。如果底层读取器实现了 io.ByteReader，它会停在当前成员之后，后面的字节仍可交给下一轮判断。

下面的最小示例把两个 gzip 成员和尾部文本拼接在一起。示例中的压缩数据由程序生成，重点是读取边界处理，不是展示任何运行截图。

package main

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

// appendMember 把一段文本编码成独立 gzip 成员并追加到目标缓冲区。
func appendMember(dst *bytes.Buffer, text string) error {
    zw := gzip.NewWriter(dst)
    // Write 的错误必须向上返回，避免把不完整成员交给后续读取。
    if _, err := zw.Write([]byte(text)); err != nil {
        _ = zw.Close()
        return err
    }
    // Close 会写入 gzip 尾部；只调用 Flush 不能完成成员封装。
    return zw.Close()
}

func main() {
    var input bytes.Buffer
    if err := appendMember(&input, "member-1\\n"); err != nil {
        panic(err)
    }
    if err := appendMember(&input, "member-2\\n"); err != nil {
        panic(err)
    }
    // 普通尾部不是 gzip 成员，供下一步展示如何保留边界。
    input.WriteString("TAIL")

    for index := 1; ; index++ {
        zr, err := gzip.NewReader(&input)
        if err == io.EOF {
            // 没有下一个完整成员；剩余字节就是尾部或空输入。
            fmt.Printf("members=%d tail=%q\\n", index-1, input.String())
            return
        }
        if err != nil {
            // ErrHeader 说明当前位置不是新的 gzip 头，通常应转为尾部处理。
            fmt.Printf("members=%d tail=%q err=%v\\n", index-1, input.String(), err)
            return
        }
        zr.Multistream(false)
        data, err := io.ReadAll(zr)
        _ = zr.Close()
        if err != nil {
            panic(err)
        }
        fmt.Printf("member %d: %q\\n", index, data)
    }
}

这里有一个容易忽略的顺序：NewReader 会先读取并解析 gzip 头，随后才调用 Multistream(false)。关闭多成员行为影响的是当前 Reader 读完成员后的继续动作，不会撤销已经完成的头部解析。

为什么要让底层读取器实现 io.ByteReader

Multistream(false) 要想把底层位置留在成员边界，底层对象需要支持按字节回看或精确推进。*bytes.Buffer 实现了 ReadByte，可以直接用于这类拼接输入；如果传入一个只实现 io.Reader 的网络包装器，gzip Reader 可能通过自己的缓冲层预读更多字节，调用者就无法把多读的尾部精确交回后续协议。

这并不意味着所有网络流都不能使用它，而是要先确认边界所有权：

• 整个连接只承载 gzip 数据：可以默认连续读取，通常不需要逐成员定位。
• gzip 后面还有自定义头、校验字节或下一种编码：使用具备 io.ByteReader 的边界输入，并让同一个对象负责后续读取。
• 输入来自不可回退的实时流：不要假设能在 gzip Reader 之外重新取回已经预读的字节，必要时在协议层统一设计缓冲。

用 Reset 循环处理下一个成员

如果已经读完当前成员，可以复用 Reader 的内部状态，调用 Reset 读取同一个底层输入中的下一段 gzip。每次 Reset 前都要先关闭或结束当前 Reader；而当输入没有下一个成员时，Reset 可能返回 io.EOF。为了区分“下一个 gzip 成员”和“普通尾部”，建议把输入封装成带 ReadByte 的缓冲对象，并先查看下一个字节，再决定是否继续创建 Reader。

package main

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

// readMembers 只读取连续 gzip 成员，并把第一个非 gzip 字节留给调用方。
func readMembers(src io.Reader) ([][]byte, *bufio.Reader, error) {
    br := bufio.NewReader(src)
    var members [][]byte

    for {
        first, err := br.Peek(2)
        if err == io.EOF || len(first) 

示例用 Peek(2) 检查 gzip 魔数 1f 8b，只是为了演示边界决策。它不是完整格式校验：真正的成员解析仍由 gzip.NewReader 完成，头部损坏、CRC 错误和截断数据仍应按返回错误处理。

io.EOF、ErrHeader 和尾部数据不要混为一谈

尤其要注意，默认 Multistream(true) 下，连续成员之间不会以一次对外可见的 EOF 分隔。只有明确关闭多成员读取，EOF 才能成为“当前成员的边界信号”。

实际项目中的选择建议

1. 如果输入只是 gzip 压缩后的连续文本，直接使用默认模式，代码更简单。
2. 如果每个 gzip 成员对应一个任务、分片或元数据块，使用 Multistream(false) 并逐成员提交。
3. 如果成员后面还有尾部协议，优先用 bufio.Reader 统一管理预读，避免字节落在不可见的内部缓冲中。
4. 把成员读取成功和业务提交分开：读取或校验失败时，不要提交半截数据。
5. 复用 Reader 时保留 Reset 的错误处理；没有下一成员不是异常，但损坏的 gzip 头和校验失败不能静默忽略。

常见问题

调用 Multistream(false) 后为什么还是读到了多个成员？

确认调用发生在当前 Reader 创建后、读取正文前，并且没有把多个 Reader 的结果在业务层无条件拼接。若已经读完第一个成员后又调用了 Reset，第二个成员当然会被继续读取。

当前成员读完返回 EOF，能否直接认为整个文件结束？

不能。在关闭多成员模式下，EOF 只表示当前成员结束；底层输入可能还有下一个 gzip 成员，也可能是普通尾部数据。

为什么自定义 io.Reader 不能保证尾部字节还在？

因为 Reader 可能为了提高效率而预读。如果底层只提供 Read 而不提供 ReadByte，调用方通常无法精确取得已经被缓冲的尾部。用统一的 bufio.Reader 或协议级缓冲对象管理边界更稳妥。

小结：要区分 gzip 成员流和尾部数据，核心不是手工解析 gzip 字节，而是关闭 Multistream 的默认连续行为，确保底层输入可精确定位，并把当前成员 EOF、下一个成员和普通尾部分别处理。这样既能保留 gzip 的校验能力，也不会让后续协议丢失边界。