Go compress/gzip Multistream 关闭后怎么继续读取拼接成员

把多个 gzip 文件直接拼在一起时，gzip.NewReader 默认会把它们当成一个连续的逻辑流。如果业务需要逐个拿到每个成员，就要在读取前调用 Multistream(false)。当前成员读到 io.EOF 后，再对同一个 Reader 调用 Reset，并重新调用一次 Multistream(false)；最后一次 Reset 返回 io.EOF，才表示后面没有新的 gzip 成员。

默认行为会把拼接成员合并读取

gzip 文件可以由多个带独立头部和尾部的成员串接而成。Go 标准库把 Reader 的多成员模式默认设为开启，因此一次 io.Copy 可能把成员 A 和成员 B 的解压结果连续写入目标，看起来像只有一个文件。

这对普通日志或压缩数据流很方便，但不适合需要按成员保留文件名、注释、校验结果或业务记录的格式。关闭多成员模式后，Read 在当前成员结束时返回 io.EOF，调用方就有了一个明确的切分点。

关闭 Multistream 后，Reader 才会停在当前成员

最小规则只有两句：在第一次读取前关闭一次；每次 Reset 之后再关闭一次。下面的示例把两个 gzip 成员放进同一个字节流，逐个读取并打印每个成员的内容。

package main

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

func readMembers(data []byte) error {
    // bytes.Reader 实现 io.ByteReader，gzip 可以停在当前成员之后。
    source := bytes.NewReader(data)
    zr, err := gzip.NewReader(source)
    if err != nil {
        return fmt.Errorf("打开第一个成员失败: %w", err)
    }
    defer zr.Close() // Close 不会关闭 source，只负责结束 Reader。

    for member := 1; ; member++ {
        // 每次只允许 Reader 解压一个 gzip 成员。
        zr.Multistream(false)
        body, err := io.ReadAll(zr)
        if err != nil {
            return fmt.Errorf("读取第 %d 个成员失败: %w", member, err)
        }
        fmt.Printf("member %d: %s\n", member, body)

        // Reset 会寻找下一个成员；没有下一个成员时返回 io.EOF。
        err = zr.Reset(source)
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return fmt.Errorf("打开第 %d 个成员失败: %w", member+1, err)
        }
    }
}

func main() {
    // 实际项目中 data 可以来自文件、网络或消息体。
    if err := readMembers(makeBundle()); err != nil {
        log.Fatal(err)
    }
}

func makeBundle() []byte {
    var bundle bytes.Buffer
    writer := gzip.NewWriter(&bundle)
    // 第一个 Close 写入第一个成员的尾部校验。
    _, _ = writer.Write([]byte("first"))
    _ = writer.Close()

    writer.Reset(&bundle)
    // 复用 Writer，把第二个成员接在同一字节流后面。
    _, _ = writer.Write([]byte("second"))
    _ = writer.Close()
    return bundle.Bytes()
}

示例里的关键不是 for，而是 Reset 的位置：必须先把当前成员完整读完，使校验和得到检查，再重置到下一个成员。如果只读一部分就重置，当前成员剩余数据和校验错误都可能被直接绕过。

Reset 后必须再次关闭 Multistream

Reset 会丢弃当前状态，并让 Reader 回到类似新建 Reader 的状态。标准库实现会把多成员标志重新设为默认的 true，所以循环里不能只在外面调用一次 Multistream(false)。否则第一轮按成员读取，第二轮又会悄悄跨过后续成员。

把它记成一个接口契约更容易：Read 负责消费当前成员，io.EOF 负责通知当前成员结束，Reset 负责定位下一个成员，Multistream(false) 负责重新声明本轮只读一个成员。

底层 Reader 和错误处理要一起设计

官方文档特别提醒：如果传给 gzip 的对象不实现 io.ByteReader，解压器可能从底层读取器预读超出当前成员的数据。要处理“gzip 成员后面还有别的格式”或必须精确切分的输入，使用 *bytes.Reader、*bufio.Reader 这类带 ReadByte 的对象更稳妥。一个常见包装方式是：

raw, err := os.Open("bundle.bin")
if err != nil {
    return err
}
defer raw.Close() // 关闭文件句柄，Reader 本身不会替你关闭它。

source := bufio.NewReader(raw) // 让底层对象保留字节边界。
zr, err := gzip.NewReader(source)
if err != nil {
    return err
}
defer zr.Close()

// 后续仍按“Read 到 EOF -> Reset -> Multistream(false)”循环。
_ = source
_ = zr

错误判断也不要混在一起：当前成员的 Read 返回 io.EOF 是正常边界；Reset 返回 io.EOF 才是整个输入结束；gzip.ErrHeader 说明下一个成员头部不合法，gzip.ErrChecksum 则表示当前成员的数据校验失败。后两种都应保留上下文并返回，而不是当作“没有下一条”吞掉。

常见问题

为什么只调用一次 Multistream(false) 不够？

因为 Reset 会重置 Reader 状态，多成员选项恢复默认开启。应把 Multistream(false) 放进每轮循环。

Reset 返回 io.EOF 是否说明最后一个成员损坏？

不一定。若前一个成员已经读到正常的 io.EOF，Reset 返回 io.EOF 通常只是说明没有下一个成员；损坏通常表现为头部错误或校验错误。

可以直接把文件对象传给 NewReader 吗？

可以读取普通单成员文件，但需要精确保留拼接边界时，优先用 bufio.NewReader(file) 作为底层对象。

因此，逐个读取拼接 gzip 的稳定写法就是：让底层 Reader 支持按字节读取，消费当前成员到 io.EOF，调用 Reset，然后再次关闭 Multistream。把两个 io.EOF 的语义分开，循环就不会把成员边界和整个输入结束混为一谈。