Go zip 解压时怎样识别 CRC 错误

Go 的 archive/zip 识别 CRC 错误，关键不在 ReadCloser.Close，而在于把条目内容持续读到结尾。File.Open 返回的 reader 会在读到 EOF 时将已读内容计算出的 CRC32 与 ZIP 元数据比较；不一致时，读取操作会返回 zip.ErrChecksum。如果只打开文件、读一小段就关闭，不能据此判断整条目完整。

CRC 校验为什么要等到读取结尾

ZIP 条目的 FileHeader.CRC32 描述的是解压后内容。Go 在 File.Open 外层包了一层校验 reader，每次读取都会累计字节并更新 CRC32；只有读到条目声明的未压缩长度后，才有足够信息完成比较。因此，CRC 错误经常出现在最后一次 Read，而不是 Open。

这一点也解释了一个常见误判：rc, _ := f.Open() 成功，只能说明条目可以建立读取链路；它不等于压缩数据已经通过完整性检查。

用完整读取捕获 zip.ErrChecksum

最稳妥的做法是把“消费内容”和“判断错误”放在同一段代码里。若业务不需要保存内容，可以直接丢弃到 io.Discard；需要落盘或解析时则换成目标 writer。下面的示例没有运行本地压缩包，代码只展示处理关系。

package main

import (
    "archive/zip"
    "errors"
    "fmt"
    "io"
)

func checkEntry(f *zip.File) error {
    rc, err := f.Open()
    if err != nil {
        return fmt.Errorf("打开条目 %q: %w", f.Name, err)
    }

    // 读取到 EOF 才能让 archive/zip 完成 CRC32 比较。
    _, readErr := io.Copy(io.Discard, rc)
    // Close 只负责释放解压 reader；读取结果仍以 readErr 为准。
    closeErr := rc.Close()
    if readErr != nil {
        if errors.Is(readErr, zip.ErrChecksum) {
            return fmt.Errorf("条目 %q CRC 校验失败: %w", f.Name, readErr)
        }
        return fmt.Errorf("读取条目 %q: %w", f.Name, readErr)
    }
    if closeErr != nil {
        return fmt.Errorf("关闭条目 %q: %w", f.Name, closeErr)
    }
    return nil
}

这里特意没有把 Close 放进无法检查结果的匿名 defer。循环中如果需要同时保留读取错误和关闭错误，显式关闭更容易记录上下文；若函数中途有多个返回路径，则可以用命名返回值配合 defer 合并错误。

读取器和 ZIP 文件要分开关闭

zip.OpenReader 返回的是文件级 *zip.ReadCloser，每个 File.Open 又会产生一个条目级 io.ReadCloser。它们是两层不同资源：先结束条目读取并关闭条目 reader，再关闭整个 ZIP 文件。对多个条目循环读取时，不要让大量条目的 defer 都拖到外层函数末尾。

func scanZip(path string) error {
    zr, err := zip.OpenReader(path)
    if err != nil {
        return err
    }
    defer zr.Close() // 外层文件资源由函数退出时释放

    for _, f := range zr.File {
        if err := checkEntry(f); err != nil {
            return err // 保留第一个能定位到条目名的读取错误
        }
    }
    return nil
}

从错误类型判断损坏位置

生产代码通常还应记录条目名、声明的未压缩大小和实际读取阶段，但不要把这些元数据当成内容完整性证明。即使长度看起来正确，CRC 仍可能失败。

提前停止读取时要知道的边界

如果业务只读取前几 KB 就停止，后面的字节没有被消费，Go 自然无法完成整条目的 CRC 比较。此时可以把它明确标成“未做完整性校验”，不要输出“校验通过”。同样，File.OpenRaw 返回的是未经解压的原始数据 reader，适合需要自己处理压缩格式的场景，不能替代默认 Open 的解压与 CRC 路径。

常见问题

为什么 Open 成功但后面仍返回 CRC 错误？

Open 只建立条目读取器，CRC 比较要等完整读取到末尾才有结果。

只检查 Close 的返回值可以吗？

不建议。Close 的职责是释放底层资源，CRC 错误应优先检查最后一次读取返回的错误。

io.Copy 读到 EOF 就一定安全吗？

只有在 io.Copy 返回 nil 后，才表示这条读取路径没有报告 CRC 或截断错误；同时仍要处理打开和关闭错误。

实际接入时可以把“完整读取、识别 zip.ErrChecksum、记录条目名、关闭两层资源”做成一个小函数。这样压缩包损坏会在最接近数据的位置暴露，而不是等到后续业务解析时才变成难定位的格式异常。