Go gzip.Reader 怎么区分截断数据与校验和错误

Go 里判断 gzip 数据是否可靠，不能只看 gzip.NewReader 是否成功，也不能在读到一部分明文后马上把结果交给下游。真正的 CRC32 和原文长度校验发生在读取 gzip trailer 时：输入或 trailer 没读完整，通常得到 io.ErrUnexpectedEOF；trailer 已读完但 CRC32 或 ISIZE 不匹配，则得到 gzip.ErrChecksum。

官方文档：https://pkg.go.dev/compress/gzip

gzip.Reader 的错误边界先看 trailer

一个 gzip 成员可以粗略看成 header、DEFLATE 压缩数据和 trailer 三段。trailer 末尾保存 CRC32 与 ISIZE，分别用于核对解压后的内容和未压缩长度。Go 源码在解压器返回 io.EOF 后，继续从底层读取这 8 个字节；这一步读不满，就把底层的 io.EOF 转成 io.ErrUnexpectedEOF。

如果 8 字节 trailer 已完整读出，但 CRC32 或 ISIZE 和 Reader 计算出的值不同，返回的就是 gzip.ErrChecksum。因此“解压出了文本”不等于“输入有效”，尤其是网络响应、对象存储分片和上传文件都可能在尾部被截断。

用 errors.Is 把两类错误分开

最稳妥的做法是把整个 Reader 读完，再按错误哨兵分类。下面的函数返回已解压字节，同时保留错误类型；注释中的判断顺序也适合直接迁移到 HTTP 响应或文件导入代码。

package gzipcheck

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

func readGZIP(src []byte) ([]byte, error) {
    // NewReader 只代表头部可识别，完整性要由后续 Read 验证。
    zr, err := gzip.NewReader(bytes.NewReader(src))
    if err != nil {
        return nil, fmt.Errorf("创建 gzip reader: %w", err)
    }
    defer zr.Close() // Close 不关闭底层 Reader，资源仍要成对释放。

    data, err := io.ReadAll(zr) // 读到 EOF 才会触发 trailer 校验。
    if err == nil {
        return data, nil // 只有正常读完，data 才能交给下游。
    }
    if errors.Is(err, io.ErrUnexpectedEOF) {
        return nil, fmt.Errorf("gzip 数据被截断: %w", err)
    }
    if errors.Is(err, gzip.ErrChecksum) {
        return nil, fmt.Errorf("gzip 校验失败: %w", err)
    }
    return nil, fmt.Errorf("读取 gzip 失败: %w", err)
}

这里不建议比较 err.Error() 字符串。errors.Is 能处理包装后的错误，后续也更容易给不同错误接入重试、告警或丢弃策略。io.ReadAll 会持续调用 Read，所以不会漏掉尾部校验。

截断、校验失败和非法头部怎么处理

多成员 gzip 还要注意 Multistream。默认情况下 Reader 会继续读取后续成员；如果设置 Multistream(false)，读完当前成员就会返回 io.EOF，底层 Reader 仍可能留在下一个成员之前。处理单个压缩块时，关闭多流能避免把后续内容误当成当前文件的一部分。

生产环境的完整读取清单

1. 先确认上游声明的格式确实是 gzip，不要把任意二进制直接交给 gzip.NewReader。
2. 将 Reader 读到正常 EOF；不要因为已经拿到部分明文就提前成功返回。
3. 用 errors.Is 分别记录截断和校验失败，日志里带上对象名、响应长度或分片编号。
4. 校验未完成前，不要落库、解码成业务对象或覆盖已有文件。
5. 若输入来自可重试网络，只有 io.ErrUnexpectedEOF 才适合优先检查传输是否中断；gzip.ErrChecksum 还要排查内容被替换、拼接或缓存污染。

常见问题

为什么只调用 gzip.Reader.Close 不能发现校验和错误？

Close 会关闭解压器，但不会替代把数据读到 EOF。gzip 的 trailer 校验在 Read 末尾执行，所以必须完整消费 Reader。

io.EOF 和 io.ErrUnexpectedEOF 有什么区别？

io.EOF 表示当前 gzip 成员正常结束；io.ErrUnexpectedEOF 表示本应存在的数据没有读够，属于结构或传输不完整。

已经解压出的字节能不能继续使用？

在成功读到 EOF 前只能视为暂定结果。若最终返回 ErrChecksum 或 ErrUnexpectedEOF，应按失败输入处理，不要把部分结果当成完整文件。