Go defer 放在循环里为什么会打开失败：从句柄上涨到及时关闭

Go 里的 defer 很好用，打开文件后顺手写一行 defer f.Close()，代码看起来干净，也不容易漏掉关闭。但如果这行代码放进一个很大的循环里，问题就可能从“优雅”变成“跑到一半打开失败”。

这篇文章用一次批量处理日志文件的场景来排查：为什么文件明明每次都写了 defer Close，程序还是提示打开失败？我们先复现现象，再看句柄数量变化，最后把修复方式落到一段可复用代码里。

摘要

defer 会在当前函数返回时触发，而不是在循环单次迭代结束时触发。如果在一个长循环里不断打开文件并 defer Close，文件句柄会一直累积，直到函数退出才统一释放。解决思路是把单个文件处理逻辑封装到小函数中，让每个文件处理结束后立即关闭。

适合人群

• 已经会写 Go 文件读写，但对 defer 触发时机不够确定的读者。
• 批量处理日志、图片、配置文件时遇到打开失败或资源占用上涨的开发者。
• 想把 Go 资源释放代码写得更稳定、更容易排查的后端同学。

问题现场：批量处理文件跑到一半报错

先看一个具体场景：我们写了一个小工具，扫描目录下的一批日志文件，逐个打开、读取、统计关键字。前面几十个文件都正常，文件一多就突然失败，报错大概是“打开文件失败，系统允许的打开文件数不够”。

第一反应可能是系统限制太小，也可能是某些文件路径不对。但代码里明明写了 defer f.Close()，看起来每个文件最终都会关闭。问题到底出在哪？

图里的关键点是：defer 已经登记了关闭动作，但这些动作没有在每次循环结束时立即触发，而是排队等当前函数返回。

第一步：先复现 defer 在循环里的写法

我们先写一段容易出问题的代码。它的意图是逐个打开文件并处理，看上去也没有明显语法错误。

package main

import (
    "fmt"
    "os"
)

func scanFiles(files []string) error {
    for _, path := range files {
        f, err := os.Open(path)
        if err != nil {
            return fmt.Errorf("open %s: %w", path, err)
        }
        defer f.Close()

        if err := scanOne(f); err != nil {
            return err
        }
    }
    return nil
}

func scanOne(f *os.File) error {
    // 这里省略读取和统计逻辑
    return nil
}

这段代码在文件数量少的时候一般看不出问题。因为函数很快返回，延迟关闭动作也很快触发。但当 files 有几千个，当前函数一直不返回，句柄就会持续堆积。

第二步：验证句柄为什么一直上涨

为了确认不是路径问题，我们可以在循环里观察当前进程打开的文件数量。Linux 环境下可以读取 /proc/self/fd 做一个简单计数。

func countOpenFiles() int {
    entries, err := os.ReadDir("/proc/self/fd")
    if err != nil {
        return -1
    }
    return len(entries)
}

func scanFiles(files []string) error {
    for i, path := range files {
        f, err := os.Open(path)
        if err != nil {
            return fmt.Errorf("open %s: %w", path, err)
        }
        defer f.Close()

        if i%100 == 0 {
            fmt.Println("index", i, "openFiles", countOpenFiles())
        }

        if err := scanOne(f); err != nil {
            return err
        }
    }
    return nil
}

如果输出里的 openFiles 随着循环不断上涨，就可以排除“某个文件偶发异常”的猜测。问题更像是资源释放时机不对。

定位原因：defer 绑定的是函数返回

现在可以定位到原因：defer 的触发点是当前函数返回，而不是当前代码块结束，也不是当前循环迭代结束。

也就是说，下面这行代码确实会关闭文件：

defer f.Close()

但它关闭的时间点是在 scanFiles 返回时。如果 scanFiles 要处理一万个文件，那么前面已经打开的文件会一直等到函数结束才关闭。这就是句柄上涨的根源。

修复方案：把单个文件处理收进小函数

最稳的改法不是放弃 defer，而是缩小它所在函数的生命周期。我们把“打开一个文件、处理一个文件、关闭一个文件”封装到独立函数里。

func scanFiles(files []string) error {
    for _, path := range files {
        if err := scanFile(path); err != nil {
            return err
        }
    }
    return nil
}

func scanFile(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return fmt.Errorf("open %s: %w", path, err)
    }
    defer f.Close()

    return scanOne(f)
}

这次 defer f.Close() 绑定的是 scanFile。每处理完一个文件，scanFile 就返回，关闭动作马上触发。外层循环继续处理下一个文件时，前一个文件的句柄已经释放。

最后验证：句柄数量保持稳定

修复后继续观察打开文件数量。预期结果不是永远固定为某一个数，而是不会随着文件序号持续上涨。

如果是在 macOS 上排查，也可以用系统自带的进程查看工具观察打开文件数量。核心不是具体工具，而是确认资源数量是否随循环持续增长。

常见误区

误区一：以为 defer 在循环末尾触发

不会。它跟函数返回绑定。循环只是在同一个函数里重复登记延迟动作。

误区二：手动 Close 后还继续使用文件

如果选择手动关闭，要确保后续不会再读取这个文件。封装函数的好处是边界更清楚，处理结束自然关闭。

误区三：所有 defer 都不能放循环里

不是绝对不能放。如果循环次数很少，或者资源对象不是稀缺资源，问题可能不明显。真正需要警惕的是长循环里打开文件、连接、响应体这类需要及时释放的对象。

总结

这次问题的关键不是 defer 错了，而是它所在的函数范围太大。放在长循环里时，关闭动作会一直等待外层函数返回，导致文件句柄堆积，最终触发打开失败。

实践上可以记住一条规则：资源需要按单次迭代释放时，就把单次处理封装成小函数，让 defer 绑定到更短的函数生命周期。这样既保留了 defer 的清晰写法，也能避免资源长时间占用。