Go 循环里 defer Close 为什么导致打开文件过多

循环里写 defer file.Close() 看起来很稳妥，但它解决的是“函数退出时清理”，不是“本轮循环结束时清理”。如果一个外层函数连续打开很多文件，循环体里的每次 defer 都会排队，直到这个外层函数返回前才执行。文件描述符便可能持续增长，最后表现为打开文件过多、打开失败，甚至让后续业务误以为是系统不稳定。

根因是作用域：defer 绑定外围函数，而不是绑定 for 的一次迭代。最简洁的修复是把单次文件处理放进独立小函数；如果不能拆函数，就在本轮处理完成后显式调用 Close，并认真处理它的错误。

为什么循环里的 defer 会拖到函数结束才执行

Go 规范规定，defer 调用会在外围函数返回前执行，并且多个 defer 按后进先出的顺序运行。循环本身没有“函数返回”这个清理时刻，所以每轮打开文件后登记的 Close 会留在同一个延迟队列里。

下面的代码在文件数量少时可能看不出问题，但它的资源峰值大致跟循环已处理的文件数一起增长：

func scanFiles(paths []string) error {
    for _, path := range paths {
        file, err := os.Open(path)
        if err != nil {
            return err // 打开失败时立即结束外层函数
        }
        defer file.Close() // 不是本轮结束，而是 scanFiles 返回前

        if err := inspect(file); err != nil {
            return err // 已登记的 Close 仍要等函数返回
        }
    }
    return nil
}

图中的关键不是“defer 不会执行”，而是它执行得太晚。os.File.Close 关闭后文件不可继续 I/O，重复关闭还会返回错误；因此不能靠垃圾回收时机替代明确的生命周期。

把单次文件处理提取成小函数

推荐把“一次打开、读取、处理、关闭”的完整任务收进辅助函数。这样 defer 的外围函数就是这一次任务，函数返回即释放当前文件，下一轮不会继承上一轮的句柄。

func inspectOne(path string) (err error) {
    file, err := os.Open(path)
    if err != nil {
        return err // 当前文件打不开，交给调用方决定是否继续
    }
    defer func() {
        if closeErr := file.Close(); err == nil {
            err = closeErr // 没有更早错误时保留 Close 错误
        }
    }()

    return inspect(file) // 返回时触发当前函数自己的 defer
}

func scanFiles(paths []string) error {
    for _, path := range paths {
        if err := inspectOne(path); err != nil {
            return err // inspectOne 已经完成本轮清理
        }
    }
    return nil
}

这里用命名返回值是为了让关闭错误有机会进入最终结果。若业务只关心读取错误，也可以使用简单的 defer file.Close()；关键仍是让它处在单次任务函数内。

必须留在同一函数时怎么显式 Close

有些代码要在同一函数里累积统计、复用局部变量，或暂时不值得拆出辅助函数。这时就不要在循环里用 defer 代替本轮清理，而是在所有文件操作完成后直接关闭：

func scanFiles(paths []string) error {
    for _, path := range paths {
        file, err := os.Open(path)
        if err != nil {
            return err // 没有成功打开的句柄需要关闭
        }

        workErr := inspect(file)
        closeErr := file.Close() // 本轮处理结束立即释放
        if workErr != nil {
            return workErr // 业务错误优先返回
        }
        if closeErr != nil {
            return closeErr // 关闭失败也属于本轮结果
        }
    }
    return nil
}

关闭位置要覆盖所有成功打开后的分支。不要只在正常路径 Close，却在中间错误处直接返回；把本轮逻辑放到小函数通常更不容易漏掉异常路径。

用这张清单判断是否真的修好

排查时可观察进程的文件描述符数量是否随批量处理持续攀升，也要区分“句柄增长”和“单个文件处理变慢”。修复后，每轮任务都应在下一轮开始前释放前一轮文件；如果仍然增长，再检查是否有其他 Reader、网络连接或临时文件没有同样收口。

常见问题

循环结束后 defer 会自动执行吗？

只有当循环所在的外围函数也返回时才会执行。若把循环放进独立函数，独立函数返回就能得到想要的及时清理。

直接写 file.Close() 会不会不够安全？

只要它位于成功 Open 后、所有处理分支都能到达的位置，就很明确；若分支复杂，使用单次处理函数加 defer 往往更容易保证清理。

忽略 Close 的错误可以吗？

只读场景有时可以记录后忽略，但写文件、同步或需要完整落盘的场景应保留并判断 Close 错误，不能把它当成无关紧要的返回值。