Go compress/gzip 怎么读取压缩成员

如果手里是一个普通的 .gz 文件，Go 读取它的关键不是自己解析压缩格式，而是把输入交给 gzip.NewReader，再像读取普通 io.Reader 一样消费解压后的字节。真正容易踩坑的是“压缩成员”：一个 gzip 文件可能串联多个独立成员。只想拿到合并后的内容，用默认模式；需要逐个识别文件名、注释或校验结果，就要关闭多成员模式并配合 Reset。

单个 .gz 文件：NewReader 之后先读出解压数据

最常见的场景是读取日志、配置备份或接口返回的 gzip 文件。gzip.Reader 本身实现了 io.Reader，所以可以直接交给 io.Copy。下面的示例把内容写进内存，便于后续解析 JSON 或文本；大文件则更适合把目标换成另一个文件或流式处理器。

package main

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

func readGzip(path string) ([]byte, error) {
    // 文件句柄由当前函数打开，因此由当前函数负责关闭。
    src, err := os.Open(path)
    if err != nil {
        return nil, err
    }
    defer src.Close()

    // NewReader 只负责解压，不会替你关闭底层 src。
    zr, err := gzip.NewReader(src)
    if err != nil {
        return nil, fmt.Errorf("创建 gzip reader: %w", err)
    }
    defer zr.Close()

    // Copy 会持续读取，直到收到 EOF；校验错误会在末尾返回。
    data, err := io.ReadAll(zr)
    if err != nil {
        if errors.Is(err, gzip.ErrChecksum) {
            return nil, fmt.Errorf("gzip 校验失败: %w", err)
        }
        return nil, fmt.Errorf("读取 gzip: %w", err)
    }
    return data, nil
}

这里有三个边界要记住。第一，NewReader 失败通常意味着头部不合法，应该保留 gzip.ErrHeader 这类错误信息。第二，底层 src 和 zr 是两个不同的资源，关闭 reader 不会关闭文件。第三，完整消费到 io.EOF 才能让 gzip 校验完成；只读到“看起来够用”的字节就提前返回，不能据此判断文件完整。

多个 gzip 成员：关闭 Multistream 后逐个 Reset

gzip 格式允许多个成员首尾相接。默认情况下，Go 会把它们当作一个连续的解压流，调用一次 io.ReadAll 得到拼接后的内容。如果业务需要知道每个成员的 Name、Comment，或者每个成员单独落盘，就要在第一次读取前调用 Multistream(false)。

package main

import (
    "bufio"
    "compress/gzip"
    "errors"
    "fmt"
    "io"
    "os"
)

func readMembers(path string) error {
    src, err := os.Open(path)
    if err != nil {
        return err
    }
    defer src.Close()

    // bufio.Reader 提供 ReadByte，让 gzip reader 在成员边界停得更准确。
    input := bufio.NewReader(src)
    zr, err := gzip.NewReader(input)
    if err != nil {
        return fmt.Errorf("第一个成员头部无效: %w", err)
    }
    defer zr.Close()

    for member := 1; ; member++ {
        // 关闭默认的串流合并，这次只处理当前成员。
        zr.Multistream(false)
        body, err := io.ReadAll(zr)
        if err != nil {
            if errors.Is(err, gzip.ErrChecksum) {
                return fmt.Errorf("成员 %d 校验失败: %w", member, err)
            }
            return fmt.Errorf("成员 %d 读取失败: %w", member, err)
        }
        fmt.Printf("成员 %d：Name=%q，字节数=%d\n", member, zr.Name, len(body))

        // Reset 让同一个 reader 读取下一个成员，避免重复分配。
        err = zr.Reset(input)
        if errors.Is(err, io.EOF) {
            return nil // 没有下一个成员，正常结束。
        }
        if err != nil {
            return fmt.Errorf("读取下一个成员: %w", err)
        }
    }
}

Multistream(false) 后，当前成员读到末尾会得到 io.EOF，但这只代表“当前成员结束”。接着调用 Reset(input)，如果还有成员就重新装载头部；如果没有，Reset 返回 io.EOF，循环即可结束。这里用 bufio.Reader 不是为了提速，而是为了让底层输入具备 io.ByteReader 能力，避免解压器为了填充缓冲区读过下一个成员的边界。

默认串流还是逐成员读取，应该怎么选

可以先看业务是否关心成员级元数据和独立失败。若只是解压后交给 JSON、CSV 或日志解析器，默认模式更简单；若每个成员对应一个独立批次，或者要记录某个成员损坏，逐成员模式更容易定位问题。

常见误判：能读出几行不等于文件完整

• 把 Close 当成校验动作：Close 不会替代完整读取；要让校验发生，先消费到结尾。
• 把多个成员当成 tar：gzip 成员只是压缩流，不提供 tar 那样的目录枚举语义；需要归档目录时应使用 archive/tar 叠加处理。
• 直接把 *os.File 当 ByteReader：逐成员读取时包一层 bufio.NewReader，让边界处理符合预期。
• 忽略 Reset 的 EOF：成员正文的 EOF 和下一个成员不存在的 EOF 处在两个不同位置，后者才是整个输入结束。

相关问题

gzip.Reader 能读取 zip 文件吗？不能。gzip 是单流压缩格式，zip 是带目录结构的归档格式；后者应使用 archive/zip。

读取网络响应体时谁负责关闭？通常由 HTTP 客户端调用方关闭响应体，gzip reader 只关闭自身解压状态；仍然要完整读取并检查末尾错误。

只想复用 gzip.Reader 怎么做？连续处理多个同类输入时可以使用 Reset，但每次更换输入后仍要按业务决定是否开启 Multistream(false)，并处理新的头部错误。

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