Go gzip.Close 为什么必须在读取完后检查错误

这个问题需要先纠正一个容易混淆的前提：对 gzip.Reader，完整性错误主要来自读取过程，不能靠 Reader.Close 补做校验。要确认 gzip 数据正常读完，应消费到 gzip.Reader 的 EOF，并检查 Read、io.Copy 或 io.ReadAll 返回的错误；随后仍应处理 Close 的返回值，但 Close 成功不等于压缩数据完整。

如果只读到业务需要的前几行就关闭，即便已经拿到可解析内容，也不能宣称整个压缩流通过了校验。gzip.Writer.Close 则是另一回事：它负责补写压缩数据和尾部，这个写入侧责任不能套到 Reader 上。

Go 官方地址：https://go.dev/

先检查对象：是 Reader.Close 还是 Writer.Close

下面只讨论读取端。假设一个报告导入器成功解析了开头几条记录，随后提前关闭 gzip.Reader，就把整份文件标为可用。应先看它是否真的读到压缩流末尾，再看读取错误有没有被丢弃。这个场景是原创说明，不是实际线上事故记录。

再检查读取错误：有返回内容也可能失败

gzip 尾部记录未压缩数据的长度及校验和。读取到结尾时发现不匹配，可以返回 gzip.ErrChecksum。损坏的输入可能在错误出现前已经交回部分解压数据，所以“解析器读到数据”不是接受整份结果的充分条件。

对需要整体可信的导入任务，可以先收集到受限的内存或临时存储，只有完整读取成功才交给后续业务。这里的“可信”仅指满足压缩格式完整性要求；gzip 校验和不是身份认证或数字签名，不证明内容来自谁。

修复写法：限定解压大小，并保留读取与关闭错误

下面的完整示例使用一个 1 MiB 的解压后大小上限。额外允许读取一个字节，用于识别超限；超限结果直接拒绝，不声称已经完成 gzip 校验。示例故意修改自己生成的小型样本的校验字段，用于说明错误判断，不修改任何外部文件。

package main

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

func decodeReport(src io.Reader) (data []byte, retErr error) {
    zr, err := gzip.NewReader(src)
    if err != nil {
        return nil, fmt.Errorf("创建解压读取器: %w", err)
    }
    defer func() {
        // 保留读取错误，关闭错误若存在则一起向上传递。
        if err := zr.Close(); err != nil {
            data = nil
            retErr = errors.Join(retErr, fmt.Errorf("关闭解压读取器: %w", err))
        }
    }()

    const maxDecoded = 1  maxDecoded {
        return nil, fmt.Errorf("报告解压后超过 %d 字节", maxDecoded)
    }
    return data, nil
}

func sample() ([]byte, error) {
    var buf bytes.Buffer
    zw := gzip.NewWriter(&buf)
    if _, err := zw.Write([]byte("report: ready\n")); err != nil {
        _ = zw.Close() // 写入已失败，尝试清理但保留主错误。
        return nil, err
    }
    // 写入侧必须完成尾部；这和 Reader.Close 的含义不同。
    if err := zw.Close(); err != nil {
        return nil, err
    }
    return append([]byte(nil), buf.Bytes()...), nil
}

func main() {
    encoded, err := sample()
    if err != nil {
        fmt.Println("构造样本:", err)
        return
    }
    good, err := decodeReport(bytes.NewReader(encoded))
    fmt.Printf("正常样本: %q, err=%v\n", good, err)

    broken := append([]byte(nil), encoded...)
    // 单个 gzip 成员尾部的前四字节是 CRC32；只修改本例的校验字节。
    broken[len(broken)-8] ^= 1
    _, err = decodeReport(bytes.NewReader(broken))
    fmt.Println("损坏样本是否为校验错误:", errors.Is(err, gzip.ErrChecksum))
}

代码使用 errors.Join，需要 Go 1.20 或更新版本。把它保存为 main.go 后可以自行运行。依据格式及接口规则，正常样本应得到报告文本，修改校验字段后的样本应被归类为 gzip.ErrChecksum；这些是示例预期，不是已经执行的日志。

为什么这里的 LimitReader 不会把“被截断的成功”伪装成可接受结果？因为达到人工上限时收集到 maxDecoded+1 字节，必然触发超限拒绝。只有未达到该人工上限、且读取没有错误时，才接受数据。不要把上限改成 maxDecoded 后仍用 len(data) == maxDecoded 直接接受：那样可能尚未触达 gzip.Reader 自己的 EOF。

判断边界：什么时候仍然不能称为完整读取

只调用 Read 一次、只读够一个结构体、只消费第一条记录，或者在外层 LimitReader 到达限制，都不必然意味着 gzip 数据已经读完。若业务本来只需要预览，应明确把结果标为预览，提前结束后关闭资源即可；没有必要为了一句“校验完成”无限制地继续解压。

默认多成员模式允许 gzip.Reader 处理串接的 gzip 成员。若主动设置 Multistream(false)，结束语义只针对当前成员，不能把第一段结束理解成整个容器都处理完成。本文示例不修改默认模式；有自定义容器格式时，应单独设计各段的边界。

如果采用流式写入数据库，不应在最后校验之前把中途记录视作最终成功。可结合事务、暂存表或任务状态延迟生效，失败时撤销尚未接受的结果。对普通输出文件，使用独立临时目标并在整体接受后交付，比直接覆盖正式结果更容易控制失败后的半成品。

收尾清单：把格式完整性与资源管理分开记录

调试时确认四件事：具体使用的 gzip 类型、读取是否真正结束、读取错误是否保留、底层输入由谁关闭。gzip.Reader.Close 不关闭传入的文件或响应体，拥有这些资源的代码仍要收尾。若读取错误被 fmt.Errorf 包装，使用 errors.Is 分类，避免依赖带上下文的整段错误文本。

错误处理也要保留主次：发生读取错误时，关闭产生的新错误不能把它覆盖；反过来，读取成功也不意味着所有资源的关闭都成功。示例通过命名返回值和 errors.Join 保留两者，交给调用方决定如何记录与退出。

相关问题

NewReader 成功是否说明压缩数据没有损坏？

不能。它能创建读取器不代表后面的压缩数据和尾部都有效，完整读取过程中仍可能报错。

io.Copy 没返回 EOF，是不是没有读完？

正常的 io.Copy 会把来源正常 EOF 作为成功结束，返回 nil。要确认来源本身就是 gzip.Reader，且没有会提前结束的外层限制；还要区分输出错误中断的情形。

只用 defer zr.Close() 是否足够？

它安排了关闭，却没有让未消费的压缩输入自动完成校验，也没有处理 Close 的返回错误。读取完整性应由读取结果负责，关闭则另行处理。

参考：gzip.Reader 与完整性约定、Reader.Close、Writer.Close、io.Copy。