Go archive/zip 怎么读取大文件而不一次载入内存

处理 ZIP 里的几百 MB 日志时，真正需要避免的是把条目内容读成 []byte 或字符串。archive/zip 的正确用法是：先打开归档并查看 Reader.File 中的目录元数据，再对选中的 File 调用 Open，用固定缓冲把 io.Reader 交给下游。这样内存主要跟缓冲区大小和条目数量有关，而不是跟单个文件的解压后大小等比例增长。

结论很简单：不要对 ZIP 条目使用 io.ReadAll；用 FileHeader 做筛选，用 File.Open 读取，用 io.CopyBuffer 处理内容，并把初始化、路径、解压和校验错误分开记录。

先看目录，再决定读哪个条目

zip.OpenReader 返回的是一个带文件句柄的 ReadCloser。它的 File 切片保存条目对象，Name、NonUTF8 和 UncompressedSize64 适合用来做筛选和审计。目录项通常以斜杠结尾，不应当被当成普通文件交给内容处理器。

下面的代码只选择一个目标文件，并在真正打开它之前检查解压后的大小。这个大小字段来自目录，适合做第一道保护；读取时仍要再次限制，因为归档可能损坏，或目录信息不值得完全信任。

package main

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

func readZipEntry(path, wanted string, dst io.Writer, maxBytes int64) error {
    r, err := zip.OpenReader(path)
    if err != nil {
        // 路径安全错误与格式错误分开记录，便于决定拒绝还是人工处理。
        if errors.Is(err, zip.ErrInsecurePath) {
            return fmt.Errorf("归档路径不安全: %w", err)
        }
        return fmt.Errorf("打开 ZIP 失败: %w", err)
    }
    defer r.Close()

    for _, f := range r.File {
        // 目录没有内容；文件名可用于匹配业务目标。
        if strings.HasSuffix(f.Name, "/") || f.Name != wanted {
            continue
        }
        if f.UncompressedSize64 > uint64(maxBytes) {
            return fmt.Errorf("条目 %q 超过大小限制", f.Name)
        }

        rc, err := f.Open()
        if err != nil {
            return fmt.Errorf("打开条目 %q 失败: %w", f.Name, err)
        }
        // 只在当前函数内关闭条目读取器，不让连接或解压资源泄漏。
        defer rc.Close()

        buf := make([]byte, 32*1024) // 固定缓冲，不按条目大小分配。
        n, err := io.CopyBuffer(dst, io.LimitReader(rc, maxBytes+1), buf)
        if err != nil {
            return fmt.Errorf("读取条目 %q 失败: %w", f.Name, err)
        }
        if n > maxBytes {
            return fmt.Errorf("条目 %q 在读取时超过大小限制", f.Name)
        }
        return nil
    }
    return fmt.Errorf("未找到条目 %q", wanted)
}

func main() {
    // 示例只把内容丢弃；生产代码可换成哈希、解析器或输出文件。
    if err := readZipEntry("logs.zip", "app/server.log", io.Discard, 512

流式读取的内存边界在哪里

关键点不是“ZIP 文件本身很小”，而是每次只让下游看到一段内容。io.CopyBuffer 会反复使用 32 KiB 缓冲，io.LimitReader 多读一个字节用来判断是否越过上限；它们都不会把整条目拼成一个大切片。若下游需要文本解析，也应让解析器消费 rc，而不是先调用 io.ReadAll(rc)。

需要注意，Reader.File 仍然要保存目录元数据，条目数量特别多时这部分内存也会增加。这里避免的是“按解压后文件大小分配内存”，并不是承诺总内存只占一个缓冲。使用 zip.NewReader 时还要提供 io.ReaderAt 和总大小，普通网络流不能直接替代这个随机访问接口。

把读取错误定位到正确层级

排查时先看错误发生在哪一层：归档打不开，说明格式或路径有问题；条目打开失败，通常要关注压缩算法；复制过程中失败，则可能是校验失败或底层读取失败。标准库提供的 zip.ErrFormat、zip.ErrInsecurePath、zip.ErrAlgorithm 和 zip.ErrChecksum 可以用 errors.Is 分类。

如果启用了 GODEBUG=zipinsecurepath=0，包含非本地路径或反斜杠的 ZIP 可能返回 ErrInsecurePath。导入外部文件时通常应拒绝这类路径；只有明确知道来源和落盘策略时，才考虑记录后继续，而且不能把条目名直接拼接到目标目录。

发布前的最小检查清单

• 是否先遍历目录并跳过目录项，而不是对整个归档做一次性读取？
• 是否用 UncompressedSize64 和读取期上限控制解压后的最大数据量？
• 每个 File.Open 返回的读取器是否在使用后关闭？
• 日志里是否保留了条目名、读取阶段和原始错误？
• 外部归档的路径是否经过本地路径策略检查？

常见问题

只遍历 r.File 会读取大文件内容吗？

不会。遍历主要访问目录条目的元数据；内容读取从调用 f.Open 并实际消费 Reader 才开始。

UncompressedSize64 能代替读取时限额吗？

不能。它适合提前拒绝明显过大的条目，读取阶段仍应使用限制 Reader 和计数，处理异常或不可信归档。

为什么不能直接对普通网络流调用 zip.NewReader？

NewReader 需要 io.ReaderAt 和总大小来访问 ZIP 目录。网络流若没有随机访问能力，应先放入可随机读取的受控存储，或使用支持该接口的封装。