Go archive/zip 校验条目关闭与错误

Go 的 archive/zip 里，“关闭”至少有三层含义：写入器的 Writer.Close 负责把中央目录写完，OpenReader 返回的归档对象负责释放底层文件，而 File.Open 返回的条目读取器负责释放当前解压流。校验错误通常发生在条目读到末尾时，不是调用某个 Close 就自动完成。

写 ZIP 时，Close 到底关闭了什么

zip.NewWriter 只是把 ZIP 结构写到一个已有的 io.Writer。每个条目的内容写完后，Writer.Close 才会追加 central directory，让归档具备完整的目录结构；它不会关闭传入的文件、缓冲区或网络响应。这里的错误必须单独处理，因为收尾阶段仍可能暴露底层写入问题。

func writeZip(path string) (err error) {
    // 由调用方创建并最终关闭底层输出文件。
    out, err := os.Create(path)
    if err != nil {
        return err
    }
    defer func() {
        // 不覆盖前面更有价值的 ZIP 写入错误；没有前错时再保留 Close 错误。
        if closeErr := out.Close(); err == nil && closeErr != nil {
            err = closeErr
        }
    }()

    zw := zip.NewWriter(out)
    entry, err := zw.Create("report.txt")
    if err != nil {
        return err
    }
    // 条目写完后才能进入下一个条目或调用 Writer.Close。
    if _, err = io.WriteString(entry, "archive content\n"); err != nil {
        return err
    }
    // Close 写入 central directory，但不会关闭 out。
    if err = zw.Close(); err != nil {
        return fmt.Errorf("finish zip: %w", err)
    }
    return nil
}

这个顺序也解释了一个常见误区：zw.Close() 成功，只能说明 ZIP 写入器完成了自己的收尾；如果输出目标是文件，还要让外层 out.Close() 走完。用命名返回值把两个错误按优先级合并，通常比在多个 defer 中静默丢错更稳妥。

读取条目时，校验错误为什么常在末尾出现

zip.OpenReader 得到的是归档级 *zip.ReadCloser；遍历某个 *zip.File 后，f.Open() 又会产生一个条目级 io.ReadCloser。File.Open 会透明解压并计算校验值，CRC 不匹配、数据不足等问题往往要等读取到 EOF 附近才暴露。因此只读取前一小段，不能证明整个条目有效。

func readEntry(path, wanted string) (data []byte, err error) {
    // 归档级资源由 OpenReader 创建，函数结束时统一释放。
    zr, err := zip.OpenReader(path)
    if err != nil {
        return nil, err
    }
    defer func() {
        // 读取错误优先保留；没有读取错误时再返回归档关闭错误。
        if closeErr := zr.Close(); err == nil && closeErr != nil {
            err = closeErr
        }
    }()

    for _, f := range zr.File {
        if f.Name != wanted {
            continue
        }
        // 条目级 ReadCloser 必须独立关闭，不能只关闭归档对象。
        rc, err := f.Open()
        if err != nil {
            return nil, err
        }
        data, err = io.ReadAll(rc)
        closeErr := rc.Close()
        if err != nil {
            // 这里可能收到 zip.ErrChecksum 或 io.ErrUnexpectedEOF。
            return nil, err
        }
        if closeErr != nil {
            return nil, closeErr
        }
        return data, nil
    }
    return nil, fmt.Errorf("entry %q not found", wanted)
}

如果业务只想判断校验失败，可以在读取返回后用 errors.Is(err, zip.ErrChecksum) 分类；如果得到 io.ErrUnexpectedEOF，更像是实际数据长度不足。两者都不应被“先返回已读字节”掩盖。条目关闭是资源管理，校验判断是读取结果，职责不同但必须在同一个调用路径里完成。

按 API 语义分配关闭和错误责任

Reader 由 NewReader 从 io.ReaderAt 和长度构造时，本身没有归档级 Close；它依赖的底层对象仍由调用方管理。另一个边界是 OpenRaw：它返回未经解压的原始内容，适合需要保留压缩字节的场景，不适合作为“已经完成内容校验”的证明。

相关问题

只调用 OpenReader.Close，还需要关闭 File.Open 吗？

需要。前者关闭归档级文件，后者关闭当前条目的读取资源；两者生命周期不同。

为什么 File.Open 成功但后续读取失败？

Open 主要建立条目读取链路，完整数据和 CRC 往往在后续读取、尤其是接近 EOF 时才被确认。

Writer.Close 成功后可以直接认为文件落盘了吗？

不能。它只完成 ZIP 结构收尾；文件同步、底层文件关闭和更强的持久化语义仍是外层输出对象的责任。