Go 循环中 defer 造成文件句柄累积的改写

我排查批量读取文件的 Go 程序时，遇到过一个很容易被忽略的现象：代码明明写了 defer file.Close()，但循环处理的文件一多，进程占用的文件句柄仍然持续增加。问题不在 Close 失效，而在 defer 绑定的是所在函数返回，不是当前这一轮循环结束。

官方文档：https://pkg.go.dev/os

循环内的 defer 会把关闭动作推迟到外层函数返回。需要每轮及时释放文件时，把一轮处理包进局部函数，或直接调用 Close 并处理返回错误。

问题现场：defer 为什么没有按循环轮次执行

下面这种写法看起来很整齐，但每次循环都会向当前函数的 defer 栈追加一个关闭动作。只有 readAll 返回时，这些动作才会按后进先出的顺序执行；如果目录里有很多文件，资源就会在函数返回前同时存活。

func readAll(paths []string) error {
    for _, path := range paths {
        file, err := os.Open(path)
        if err != nil {
            return fmt.Errorf("open %s: %w", path, err)
        }
        defer file.Close() // 绑定 readAll 的返回，不是本轮 for 的结束

        if err := consume(file); err != nil {
            return fmt.Errorf("consume %s: %w", path, err)
        }
    }
    return nil
}

所以排查时先看资源创建点和函数边界：如果 os.Open 在长循环里，而 defer Close 也在同一个长函数里，就要把“何时释放”当成独立问题处理。

动手验证：把一轮处理放进局部函数

最小改写是让每次迭代调用一个局部函数。此时 defer 属于这个局部函数；函数返回后，当前文件就会关闭，下一轮不会继续累积上一轮的句柄。

func readAll(paths []string) error {
    for _, path := range paths {
        err := func() error {
            file, err := os.Open(path)
            if err != nil {
                return fmt.Errorf("open %s: %w", path, err)
            }
            defer func() {
                // 关闭动作绑定本轮局部函数的返回时刻。
                _ = file.Close()
            }()

            if err := consume(file); err != nil {
                return fmt.Errorf("consume %s: %w", path, err)
            }
            return nil
        }()
        if err != nil {
            // 保留当前路径，便于定位是哪个文件处理失败。
            return err
        }
    }
    return nil
}

这里的关键不是匿名函数本身，而是新增了一个明确的函数作用域。匿名函数返回时，defer 立即执行。关闭错误如果对业务很重要，可以把关闭动作改成具名返回值或单独返回；示例只表示“关闭失败不应覆盖读取错误”的常见取舍。

定位原因：什么时候应当显式 Close

如果循环体本身已经包含多个分支，或者关闭错误必须进入统一的错误统计，直接显式关闭通常更直白。此时要注意：成功读取后也要关闭；读取失败时也要关闭已经打开的文件，不能只在成功分支调用。

func readAll(paths []string) error {
    for _, path := range paths {
        file, err := os.Open(path)
        if err != nil {
            return fmt.Errorf("open %s: %w", path, err)
        }

        consumeErr := consume(file)
        closeErr := file.Close() // 直接在本轮结束前释放文件句柄
        if consumeErr != nil {
            return fmt.Errorf("consume %s: %w", path, consumeErr)
        }
        if closeErr != nil {
            return fmt.Errorf("close %s: %w", path, closeErr)
        }
    }
    return nil
}

把 consumeErr 和 closeErr 分开保存，是为了避免关闭动作掩盖真正的读取错误。若业务允许继续处理后续文件，可以把错误追加到收集器中，而不是立即 return；但资源释放点仍应留在当前迭代内。

改写选择：局部函数还是显式关闭

可以把规则记成一句话：defer 应该贴近资源所属的最小函数作用域。如果最小作用域就是一次循环迭代，就用局部函数表达它；如果需要精细处理多个错误，就显式关闭。

相关问题

循环里的 defer 一定会造成泄漏吗？ 不一定。它会延迟到所在函数返回；如果循环很短、资源很少，风险可能不明显，但长批处理应主动缩小作用域。

为什么不直接忽略 Close 的错误？ 只读文件通常可以按业务取舍，但写文件、同步落盘或需要审计的场景应保留关闭错误并决定是否失败。

局部函数会让代码变慢吗？ 它首先解决的是生命周期和可读性。是否有可感知开销要结合实际批量规模评估，不应为了猜测的微小开销把资源释放推迟到外层函数末尾。

这类问题最后通常不是“少写一个 defer”，而是重新画清函数边界：每轮打开的文件应该在每轮自己的工作完成后释放。只要让 defer 属于正确的作用域，批量读取就能同时保留提前返回的安全性和可控的资源占用。