Go archive/zip NewReader 如何处理非 Seekable 输入：临时文件与流式解压边界

下载接口返回的是 io.Reader，手里却要调用 zip.NewReader，这时编译器会先提醒你：顺序读取和随机读取不是一回事。NewReader 需要 io.ReaderAt，还要知道 ZIP 文件的准确字节数；不能把一个只会从头读到尾的网络流直接塞进去。

输入不大就先读成 bytes.Reader；输入可能较大或大小未知，就复制到临时文件，再用文件句柄和实际大小调用 zip.NewReader。若业务本来只需要按顺序解压，则改用流式 ZIP 方案，不要为了凑接口强行缓存整包。

为什么顺序流不能直接交给 zip.NewReader

zip.NewReader 的签名是 NewReader(r io.ReaderAt, size int64)。ZIP 的中央目录位于文件尾部，读取器需要先定位目录，再按偏移取回条目头和内容，所以接口必须支持 ReadAt。而 io.Reader 只承诺下一段数据，读过的字节通常不会自动回到原位置。

这也是第二个参数不能随便填的原因。size 不是“预计大小”，而是读取范围的边界。填小会让中央目录不可见，填大则可能把无关尾部当成 ZIP 数据的一部分。先确认数据来源能提供真实长度，再决定内存或磁盘方案。

小文件用 bytes.Reader 把接口补齐

如果压缩包有明确的小尺寸上限，最短路径是一次性读取。io.ReadAll 得到字节切片，bytes.NewReader 同时提供顺序读取和偏移读取能力，切片长度就是可靠的 size。

func openSmallZip(src io.Reader, maxSize int64) (*zip.Reader, error) {
    data, err := io.ReadAll(io.LimitReader(src, maxSize+1))
    if err != nil {
        return nil, err
    }
    if int64(len(data)) > maxSize {
        return nil, fmt.Errorf("zip: input exceeds %d bytes", maxSize)
    }
    return zip.NewReader(bytes.NewReader(data), int64(len(data)))
}

这里的 maxSize+1 是为了识别超限，不是 ZIP 自己的限制。实际项目还要根据内存预算设定上限，并对空数据、坏格式和压缩炸弹风险做单独处理。读取完整包并不等于信任其中的解压后大小。

大小未知时用临时文件承接网络输入

大文件或长度不可信时，更稳妥的做法是把顺序流落到磁盘。os.CreateTemp 返回的文件既能顺序写入，也能在复制结束后作为 io.ReaderAt 使用；Stat 得到的实际大小再传给 NewReader。

func openTempZip(src io.Reader) (*zip.Reader, func() error, error) {
    f, err := os.CreateTemp("", "go-zip-*")
    if err != nil {
        return nil, nil, err
    }
    cleanup := func() error {
        name := f.Name()
        closeErr := f.Close()
        removeErr := os.Remove(name)
        if closeErr != nil {
            return closeErr
        }
        return removeErr
    }

    if _, err = io.Copy(f, src); err != nil {
        _ = cleanup()
        return nil, nil, err
    }
    info, err := f.Stat()
    if err != nil {
        _ = cleanup()
        return nil, nil, err
    }
    zr, err := zip.NewReader(f, info.Size())
    if err != nil {
        _ = cleanup()
        return nil, nil, err
    }
    return zr, cleanup, nil
}

调用方必须在遍历并读取所有条目后执行返回的 cleanup。如果要把 *zip.Reader 交给异步任务，不能先关闭并删除临时文件；应把“使用完成”纳入任务生命周期。生产代码还可在 io.Copy 外包一层限流或限长读取器。

只需要顺序解压时别强行使用 NewReader

如果业务只想逐个读取网络响应里的 ZIP 条目，并不需要跳转中央目录或按名称随机打开，应该选择支持顺序输入的流式 ZIP 实现。标准库 archive/zip 的 NewReader 明确要求 ReaderAt，不能靠包装一个简单的 bufio.Reader 来改变这个事实。

这个判断很实用：内存方案换来简单生命周期，临时文件换来较低的内存峰值，流式方案换来更早的首条结果，但通常牺牲按名称定位和部分随机访问能力。先看后续操作，再选承接方式。

打开条目时把路径和清理一起验掉

拿到 zr.File 后，不要只检查文件名后缀。使用 File.Open 后要及时关闭条目读取器，并对来自不可信压缩包的路径保持警惕。当前 Go 文档说明，启用 GODEBUG=zipinsecurepath=0 时，包含非本地路径或反斜杠的 ZIP 会返回 ErrInsecurePath；是否继续使用返回的读取器，应由业务安全策略决定。

for _, entry := range zr.File {
    rc, err := entry.Open()
    if err != nil {
        return err
    }
    err = func() error {
        defer rc.Close()
        _, err := io.Copy(dst, io.LimitReader(rc, maxEntrySize))
        return err
    }()
    if err != nil {
        return err
    }
}

示例中的 maxEntrySize 是业务自己的解压后单文件上限，不能把它误认为 ZIP 库提供的安全保证。还应限制条目数量、总解压量，并把目标路径规范化到允许的根目录内。

常见问题

io.SectionReader 能不能替代临时文件？

可以，但前提是底层对象已经实现 io.ReaderAt，并且你能正确给出切片范围。它适合已有随机读取源，不会把一个网络流凭空变成随机读取源。

NewReader 的 size 能不能传文件当前偏移？

不能。应传 ZIP 数据区域的字节数；对普通文件通常是 Stat().Size()，而不是当前 seek 位置。

读取完 ZIP 后什么时候删除临时文件？

所有条目读取完成、zip.Reader 不再被使用后再关闭文件并删除。异步传递读取器时，清理动作必须跟着异步任务结束。

最后的选择

能控制大小的小包用 bytes.Reader，大小未知或可能较大的输入落到临时文件，只做顺序消费则改用流式读取。无论选哪条路径，都要让 ReaderAt、size、资源清理和解压边界在代码里各自可见，这样排错时不会把接口不匹配误判成 ZIP 文件损坏。