Go zlib 解压报校验和错误怎么办

Go zlib 解压出现 zlib: invalid checksum 时，不要忽略错误后继续使用已解出的内容。先保留 NewReader、读取和 Close 三个位置的错误：校验和不匹配通常在读到压缩流末尾时报告，尾部缺失则可能表现为 io.ErrUnexpectedEOF。修复重点是找回完整且未被改动的输入，并确认上游压缩器成功关闭，而不是让解压器跳过校验。

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

先确认错误发生在创建还是读取阶段

NewReader 返回成功，只代表解压器初始化成功，不代表整段数据已完整解压。只读了前几行文本就停止，也不能证明尾部校验正确。Reader 的校验和检查依赖完整消费压缩流；Close 负责释放解压器资源，不会替你把没读完的流读完。

把排查记录拆成创建错误、读取错误和关闭错误。若读取时已经报错，关闭时也可能返回同一个已记录的错误，这不等于出现了第二个独立故障。不要只记最后一次调用的错误，覆盖真正的读取原因。

构造样本时，先让压缩器正常结束

下面的小实验只使用自己生成的短文本，便于把输入截断和尾部校验字段改动分开观察。压缩器的 Write 成功并不代表缓冲区已经包含完整压缩流，必须处理 Writer.Close 的错误，再取得缓冲区内容。仅调用 Flush 不能替代结束压缩流。

示例不用文件、网络或外部依赖。实际业务如果在压缩器外还有缓冲写入器，需要按各层约定完成写入并保留错误；不要把“压缩器已关闭”直接当成外层传输或落盘已经完成。

完整读取，并把失败结果留在函数内部

unpackSmall 用 io.ReadAll 读取受控的小样本，然后显式关闭解压器。只有读取与关闭均成功才返回正文；读取失败时，即使已有部分数据，也返回空结果和可追踪的错误。这里使用 errors.Join 保留错误链，调用者仍可用 errors.Is 判断具体原因。

package main

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

func packSmall(src []byte) ([]byte, error) {
    var buf bytes.Buffer
    zw := zlib.NewWriter(&buf)
    // 即使写入失败也关闭压缩器；两个错误都保留。
    _, writeErr := zw.Write(src)
    closeErr := zw.Close()
    if err := errors.Join(writeErr, closeErr); err != nil {
        return nil, fmt.Errorf("生成压缩样本: %w", err)
    }
    // 只在压缩器关闭成功之后取出完整压缩数据。
    return append([]byte(nil), buf.Bytes()...), nil
}

func unpackSmall(src []byte) ([]byte, error) {
    zr, err := zlib.NewReader(bytes.NewReader(src))
    if err != nil {
        return nil, fmt.Errorf("创建解压器: %w", err)
    }
    // 仅面向本文受控的小样本；读取到末尾才有机会检查校验和。
    data, readErr := io.ReadAll(zr)
    closeErr := zr.Close()
    if readErr != nil {
        // 不能将已经解出的前缀当作完整、可信的正文返回。
        return nil, fmt.Errorf("读取解压数据: %w", errors.Join(readErr, closeErr))
    }
    if closeErr != nil {
        return nil, fmt.Errorf("关闭解压器: %w", closeErr)
    }
    return data, nil
}

func main() {
    packed, err := packSmall([]byte("inventory=ready\nitems=3\n"))
    if err != nil {
        panic(err)
    }
    // 两个异常样本各自复制，避免改动正常样本的底层数组。
    truncated := append([]byte(nil), packed[:len(packed)-1]...)
    changed := append([]byte(nil), packed...)
    changed[len(changed)-1] ^= 1 // 仅改动末尾校验字段的一个比特。

    cases := []struct {
        name string
        data []byte
    }{
        {"完整输入", packed},
        {"缺少尾字节", truncated},
        {"改动校验字段", changed},
    }
    for _, c := range cases {
        data, err := unpackSmall(c.data)
        // 使用errors.Is识别被包装或合并的错误，不匹配错误字符串。
        switch {
        case err == nil:
            fmt.Printf("%s: 成功，正文=%q\n", c.name, data)
        case errors.Is(err, zlib.ErrChecksum):
            fmt.Printf("%s: 校验和不匹配，正文不交付\n", c.name)
        case errors.Is(err, io.ErrUnexpectedEOF):
            fmt.Printf("%s: 输入未完整结束，正文不交付\n", c.name)
        default:
            fmt.Printf("%s: %v\n", c.name, err)
        }
    }
}

代码中的 packSmall 是样本生成器，unpackSmall 是交付边界。前者保证样本在压缩器正常结束后取出，后者保证失败的解压内容不会被误当成功结果返回。两者都不依赖某一组固定压缩字节。

运行对照样本时，分别观察三种判断

将完整代码保存为 main.go，在支持代码所用标准库接口的 Go 环境自行运行。以下为预期判断，不是已经执行的终端输出：

实验只改动最后一个字节，因此不会破坏前面的压缩载荷。真实数据在其他位置被改动时，可能直接产生解压格式错误，不一定都是 ErrChecksum。同样，真实读取器还可能返回自身的 I/O 错误，不能把所有失败都归为“文件损坏”。

若采用自行循环读取，必须同时处理每次调用返回的字节数与错误；一次读取可能同时返回数据和错误。业务可以将内容暂存，但只有完整读取成功后才能认定这段 zlib 内容通过完整性检查。

修复输入来源，不用 Close 掩盖错误

对 ErrChecksum，先对照生产端保存的原始压缩字节，排查传输、存储和文本转换环节是否改动数据。对 ErrUnexpectedEOF，优先检查输入是否收齐、是否提前切片、是否在压缩器关闭之前读取缓冲区。错误是定位入口，不足以单凭一个错误值断言具体是哪一环节的问题。

解压器的 Close 不会关闭传给 NewReader 的底层读取器。如果底层是你打开的文件或响应体，还需要按所有权约定单独关闭；本文内存读取器没有这类外部资源。不要通过“只调用 Close、不读完”来确认校验成功。

示例的 io.ReadAll 仅适合已知很小的受控数据。对不受信任或可能很大的输入，需另设解压大小和资源限制；如果因达到限制而提前停止，就应报告超限或未完成，不能宣称已经检查了完整流。本文不提供面向任意输入的无界解压服务。

已经拿到了完整文本，为什么仍要拒绝？

文本看起来完整不代表尾部记录匹配。失败时可以将隔离副本用于排查，但不要把它作为正常成功结果交给下游。zlib 的校验和也不是来源认证或防篡改签名。

defer Close 能解决问题吗？

defer 能帮助安排关闭动作，但不会自动让读取完成，也不会自动把关闭错误交给调用者。像示例这样显式收集关闭错误，更容易区分读取失败与清理结果。

修复后该看什么？

保留原有失败样本用于本地对照，重新取得完整输入，确认读取能正常到达流末尾，再处理关闭结果。核心判据是完整消费后的错误状态，而不是 NewReader 是否成功，或日志里是否已经打印出正文。

实现细节参考：https://go.dev/src/compress/zlib/reader.go