Go zip.File.Open未关闭导致压缩条目资源滞留的排查

在 Go 中遍历 ZIP 条目时，zip.File.Open 返回的是 io.ReadCloser，它不会因为循环进入下一次迭代就自动释放。排查“压缩条目资源滞留”时，核心做法是把单条目处理放进小函数，让 defer rc.Close() 在该条目结束时执行，再用 io.LimitReader 给解压后的读取量设上限。这样既不会把关闭动作拖到整个归档处理结束，也不会无界读取异常大的条目。

先拆开 zip.File.Open 的两个资源层次

zip.OpenReader 管的是整个归档文件，f.Open() 管的是某一个条目的解压读取器。官方文档把后者定义为提供条目内容的 io.ReadCloser，因此遍历结束前必须逐个关闭。外层关闭只能回收归档读取器，不能替代条目级关闭。

常见问题是把 defer rc.Close() 写在遍历函数内部。语法没有错，但所有关闭动作都等外层函数返回才发生；当归档包含很多条目时，打开的 Reader 会同时存活更久。

把 defer 放进单条目函数，释放点才可控

下面的写法让每次循环调用 readEntry，函数返回就释放当前 Reader。代码还保留了 Open、复制和 Close 三类错误，避免用一个看似成功的计数掩盖归档损坏。

package main

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

// readEntry 只处理一个条目，让 defer 在当前条目结束时执行。
func readEntry(f *zip.File, maxBytes int64) (data []byte, err error) {
    rc, err := f.Open()
    if err != nil {
        return nil, fmt.Errorf("open %s: %w", f.Name, err)
    }
    // 关闭错误也属于处理结果，不能被无声吞掉。
    defer func() {
        if closeErr := rc.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close %s: %w", f.Name, closeErr)
        }
    }()

    // 受限读取避免把异常大的解压内容一次性装入内存。
    limited := io.LimitReader(rc, maxBytes+1)
    data, err = io.ReadAll(limited)
    if err != nil {
        return nil, fmt.Errorf("read %s: %w", f.Name, err)
    }
    if int64(len(data)) > maxBytes {
        return nil, fmt.Errorf("entry %s exceeds %d bytes", f.Name, maxBytes)
    }
    return data, nil
}

这里用 maxBytes+1 是为了识别“刚好超过上限”的情况；如果只读到 maxBytes，调用方无法区分内容恰好到达上限还是后面仍有数据。若业务只需要流式写入目标文件，也可以把 io.ReadAll 换成带上限的 io.Copy。

读取上限与错误处理要分成两条判断

条目 Reader 已经限制读取后，还要在调用方区分“达到业务上限”和“归档内容读取失败”。上限属于策略拒绝，应该记录条目名和实际限制；checksum 错误、解压算法不支持或底层 I/O 错误，则应保留原始错误链。

路径、并发和 Close 错误的复核边界

zip.File.Name 是归档内名称，不应直接拼成宿主机绝对路径。需要落盘时，先做相对路径和目录穿越检查，再把安全后的目标路径交给文件系统。并发处理虽然可行，但应使用固定大小的 worker 池；每个 worker 仍要在单条目函数中关闭 Reader。

如果业务要求确认关闭失败，可以改用显式关闭并把错误合并到返回值；若只是读取并丢弃，至少不能让 Close 失去执行机会。最终检查四项：每个成功 Open 都对应一次 Close、读取有上限、错误含条目名、并发有预算。

常见问题

外层 zip.ReadCloser.Close 了，还需要关闭 f.Open 返回值吗？

需要。两者对应不同层次的 Reader，外层关闭不替代条目 Reader 的关闭。

为什么不建议在循环里直接 defer？

因为 defer 绑定当前函数，而不是绑定循环迭代；长循环会让已打开的 Reader 存活到外层函数返回。

io.LimitReader 能防止压缩炸弹吗？

它能限制当前条目交给业务读取的字节数，但还应限制条目数量、并发数和总处理预算，不能把单一上限当成完整防护。

参考事实：Go 标准库 archive/zip 官方文档 https://pkg.go.dev/archive/zip，其中说明 File.Open 返回 io.ReadCloser，ReadCloser 在不再使用时必须关闭。