Go defer 在循环里为什么没有及时关闭文件

我第一次遇到这个问题，是在一个需要逐个读取目录文件的任务里。代码看起来很符合直觉：打开文件后立刻写 defer file.Close()，然后进入下一轮循环。结果文件数量一多，句柄并没有随着每轮结束而下降。

原因是 defer 绑定的是包含它的函数，不是 for 循环的一次迭代。把它直接写在大循环里，所有延迟调用都会等外围函数返回后才执行。

官方资料把 defer 描述为“在外围函数返回后执行”的延迟调用，并且多个 defer 按后进先出顺序处理。本文只讨论文件读取这一种资源场景，最后给出两种写法的选择边界。

官方资料：https://go.dev/blog/defer-panic-and-recover　https://pkg.go.dev/os#File.Close

为什么 defer 不会在每轮循环后执行

下面这段代码的问题不在 defer 本身，而在它所在的函数太大：

func processFiles(paths []string) error {
	for _, path := range paths {
		file, err := os.Open(path)
		if err != nil {
			return err // 打开失败时没有可关闭的文件
		}
		defer file.Close() // 清理登记到 processFiles 的延迟栈

		if err := consume(file); err != nil {
			return err // 返回 processFiles 时才统一执行 defer
		}
	}
	return nil
}

每次循环都会向 processFiles 的延迟栈追加一个关闭调用。循环体结束只代表本轮代码走完，并不代表 processFiles 返回，因此文件句柄会在函数运行期间持续占用。文件多、单个文件处理慢，或者函数中间还有等待时，这个差异就会变成“打开文件过多”。

还要注意一个容易混淆的点：defer file.Close() 的参数在登记时就确定了，但调用本身仍然等外围函数返回才发生。它不会因为下一轮重新赋值给变量，就自动提前关闭上一轮文件。

我更常用的方案：把单次读取包进局部函数

如果单个文件的读取逻辑不止两三行，我会把它放进一个局部函数。这样每轮调用都有独立的函数边界，defer 仍然保持“打开后马上登记清理”的可读性：

func processFiles(paths []string) error {
	for _, path := range paths {
		if err := func() error {
			file, err := os.Open(path)
			if err != nil {
				return err // 打开失败直接结束本轮任务
			}
			defer func() {
				_ = file.Close() // 关闭动作绑定到本次局部函数返回
			}()

			return consume(file) // 返回时执行本轮 defer
		}(); err != nil {
			return err // 把本轮错误交给外围函数决定是否停止
		}
	}
	return nil
}

这段写法的关键不是“用了匿名函数”，而是每次迭代都创建了一个独立的调用边界。局部函数返回后，当前文件的清理动作就有机会执行，下一轮不会继续叠加上一轮的文件句柄。

如果关闭错误也必须反馈给调用方，可以把清理写成命名返回值配合的形式：

func readOne(path string) (err error) {
	file, err := os.Open(path)
	if err != nil {
		return err // 打开失败时不登记关闭动作
	}
	defer func() {
		if closeErr := file.Close(); err == nil && closeErr != nil {
			err = closeErr // 没有更早错误时保留关闭错误
		}
	}()

	return consume(file) // 读取错误优先于关闭错误返回
}

简单循环也可以直接 Close

不是所有循环都需要局部函数。如果读取逻辑短、关闭错误需要在当前循环点处理，显式关闭往往更直观：

func processFiles(paths []string) error {
	for _, path := range paths {
		file, err := os.Open(path)
		if err != nil {
			return err // 当前文件打不开就停止处理
		}

		readErr := consume(file)
		closeErr := file.Close() // 本轮结束前明确释放文件资源
		if readErr != nil {
			return readErr // 读取失败优先返回
		}
		if closeErr != nil {
			return closeErr // 读取成功时再报告关闭失败
		}
	}
	return nil
}

显式 Close 的代价是错误分支需要自己安排好优先级：通常先保留读取或处理错误，只有前面没有错误时才返回关闭错误。若中间增加了多个提前返回点，手写清理就更容易漏掉，这时局部函数方案更稳。

按这张表选择，不要只看代码长短

我自己的判断是：先看资源的生命周期，再看哪种写法更短。只要一个循环可能打开很多文件，就不要把 defer file.Close() 直接放在长生命周期的外围函数里；局部函数的几行封装，通常比排查句柄耗尽更便宜。

几个容易混淆的问题

循环变量变化会让 defer 关闭错文件吗？

单纯因为下一轮改变变量，并不会让已经登记的调用自动改成另一个资源。真正需要关注的是延迟调用属于哪个函数，以及资源是否在这个函数返回前一直占用。

只要用了 defer 就一定不适合循环吗？

不是。把一次迭代封装成独立函数后，defer 仍然是很合适的清理方式。需要避免的是把许多迭代的清理动作都堆到同一个长生命周期函数上。

最后记住一句：defer 的释放时机由函数边界决定。循环内资源要按轮次释放，就让每轮拥有自己的函数边界，或者在本轮明确调用 Close。