archive/zip File.Open 后如何及时关闭归档内文件

archive/zip.File.Open 返回的不是普通的只读对象，而是一个需要调用 Close 的 io.ReadCloser。最稳妥的写法是在 Open 成功后立刻安排关闭，让读取失败、复制失败和提前返回都不会漏掉资源释放。

这里要分清两层对象：zip.OpenReader 管的是整个 ZIP 文件，zip.File.Open 管的是某一个归档条目的内容读取器。关闭条目读取器不会替代关闭外层归档文件，反过来也不能用外层关闭动作代替当前条目的收尾。

先分清 ZIP 阅读器和条目读取器

官方文档把 zip.File 定义为 ZIP 中的单个文件，条目内容通过 File.Open 访问。File.Open 返回 io.ReadCloser，它同时提供读取接口和关闭接口；文档还说明多个条目可以并发读取，但每个返回的读取器仍然有自己的生命周期。

容易混淆的地方是：*zip.File 看起来像文件，但真正需要在读取后关闭的是 File.Open 返回的接口值。不要围绕 zip.File 本身寻找一个不存在的条目关闭方法。

在 File.Open 成功后立即安排 Close

单条目读取时，把 defer rc.Close() 紧跟在错误判断后面，是最不容易遗漏的边界。代码不依赖某一次实现是否已经读完底层数据，而是明确表达“这个函数拥有该读取器直到返回”的责任。

package main

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

func readEntry(zf *zip.File) ([]byte, error) {
    rc, err := zf.Open()
    if err != nil {
        return nil, fmt.Errorf("打开归档条目 %q: %w", zf.Name, err)
    }
    // Open 成功后立刻登记关闭，后面的读取错误和提前返回都会经过这里。
    defer func() {
        if closeErr := rc.Close(); closeErr != nil {
            // 这里不能覆盖已经返回的读取错误；生产代码可接入日志或指标。
            fmt.Printf("关闭归档条目 %q 失败: %v\\n", zf.Name, closeErr)
        }
    }()

    data, err := io.ReadAll(rc)
    if err != nil {
        return nil, fmt.Errorf("读取归档条目 %q: %w", zf.Name, err)
    }
    return data, nil
}

这个示例把关闭错误记录出来，但没有让关闭错误覆盖读取错误。因为 io.ReadAll 已经报告了更早发生的失败时，调用方通常更需要保留原始读取原因；如果业务把关闭失败视为必须返回的错误，应使用具名返回值明确规定优先级，而不是在匿名函数里悄悄改写结果。

在循环读取多个条目时缩短 defer 作用域

单个函数里遍历很多条目时，直接在循环体里写 defer rc.Close() 会把每次关闭推迟到外层函数结束。条目数量较大时，未关闭的读取器会同时存在，资源峰值也更难控制。更清楚的做法是把一次迭代放进小函数，让 defer 在当前条目处理完就执行。

func copyEntries(files []*zip.File, dst io.Writer) error {
    for _, zf := range files {
        if err := func() error {
            rc, err := zf.Open()
            if err != nil {
                return fmt.Errorf("打开 %q: %w", zf.Name, err)
            }
            // 小函数的返回点就是单个条目的资源边界，defer 不会拖到整个循环结束。
            defer func() {
                if closeErr := rc.Close(); closeErr != nil {
                    fmt.Printf("关闭 %q 失败: %v\\n", zf.Name, closeErr)
                }
            }()

            // Copy 会持续读取到 EOF，并把读取或写入错误返回给当前条目。
            if _, err := io.Copy(dst, rc); err != nil {
                return fmt.Errorf("复制 %q: %w", zf.Name, err)
            }
            return nil
        }(); err != nil {
            return err
        }
    }
    return nil
}

如果条目处理还需要更新索引、写入数据库或切换输出文件，仍然可以沿用这个小函数边界。关键不是机械追求“少写一个 defer”，而是让一个 Open 和它对应的 Close 出现在同一个可读的生命周期内。

处理 OpenReader 与条目 Close 的双层责任

从磁盘读取 ZIP 时，外层通常这样打开：

func readZip(path string, dst io.Writer) error {
    zr, err := zip.OpenReader(path)
    if err != nil {
        return fmt.Errorf("打开 ZIP %q: %w", path, err)
    }
    // ReadCloser 绑定了磁盘上的归档文件，函数结束前要关闭它。
    defer func() {
        if closeErr := zr.Close(); closeErr != nil {
            fmt.Printf("关闭 ZIP %q 失败: %v\\n", path, closeErr)
        }
    }()

    for _, zf := range zr.File {
        if err := func() error {
            rc, err := zf.Open()
            if err != nil {
                return fmt.Errorf("打开条目 %q: %w", zf.Name, err)
            }
            // 条目读取器与外层归档是两种资源，必须各自收尾。
            defer func() {
                if closeErr := rc.Close(); closeErr != nil {
                    fmt.Printf("关闭条目 %q 失败: %v\\n", zf.Name, closeErr)
                }
            }()

            if _, err := io.Copy(dst, rc); err != nil {
                return fmt.Errorf("读取条目 %q: %w", zf.Name, err)
            }
            return nil
        }(); err != nil {
            return err
        }
    }
    return nil
}

这里有两个独立的 Close：外层 zr.Close() 释放打开的 ZIP 文件，内层 rc.Close() 结束当前条目的解压读取器。若是用 zip.NewReader 从内存或其他 io.ReaderAt 构造 *zip.Reader，则没有外层 ReadCloser 可关，但每次 File.Open 返回的条目读取器仍然按同样规则处理。

用清单检查早退和错误传播

• Open 失败：没有拿到读取器，不要调用 Close，直接保留带条目名的错误。
• Open 成功：立刻安排 Close，不要等读完以后再临时补写。
• 读取或复制失败：返回原始错误，同时让已登记的关闭动作执行。
• 循环读取：用小函数缩短 defer 的作用域，避免所有条目都等外层函数结束才释放。
• 磁盘 ZIP：关闭 *zip.ReadCloser；条目读取器仍然要单独关闭。
• 内存 Reader：没有外层 ZIP 文件句柄时不虚构关闭动作，但对每个 File.Open 结果照常关闭。

结论：谁创建资源，谁负责把它收好

archive/zip.File.Open 的核心规则可以压缩为一句话：成功拿到 io.ReadCloser 后立即登记 Close，并让这个登记的作用域覆盖所有可能的返回路径。遍历条目时把每次处理放进小函数；使用 OpenReader 时，再额外关闭代表整个 ZIP 文件的外层 ReadCloser。

相关问题

io.ReadCloser 读到 EOF 后还要 Close 吗？

要。读到 EOF 只表示当前读取操作结束，不应替代接口约定的关闭动作。把 Close 放进打开成功后的统一收尾路径，代码边界更稳定。

关闭条目读取器会关闭整个 ZIP 吗？

不会。File.Open 返回的读取器只对应当前条目；通过 OpenReader 得到的外层 ReadCloser 仍由调用方负责关闭。

可以把所有条目的读取器保存起来，最后统一 Close 吗？

技术上可以保存接口值，但这会扩大资源峰值和错误处理范围。除非确实需要并发读取，否则逐条处理并在小作用域内关闭更容易控制。