Go defer 在循环里延迟关闭文件为什么耗尽句柄

循环里打开文件后写下 defer f.Close()，短数据集可能看不出问题，文件一多却会出现“打开文件过多”、句柄耗尽，甚至后续完全无法创建新文件。原因不是 defer 失效，而是它绑定的是当前函数返回：循环体没有独立函数边界，所以所有关闭动作都会排到外层函数结束时。

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

Go 的 defer 按后进先出顺序，在所在函数即将返回时执行。下面的写法每次循环都会注册一次关闭动作，但外层函数还没有返回，文件就一直保持打开：

func scanFiles(paths []string) error {
	for _, path := range paths {
		// 每轮打开一个文件，但 defer 的边界是 scanFiles 返回。
		f, err := os.Open(path)
		if err != nil {
			return err
		}
		defer f.Close()
		if _, err := io.Copy(io.Discard, f); err != nil {
			return err
		}
	}
	return nil
}

当 paths 很大时，打开数会接近迭代次数。遇到 EMFILE 一类错误时，先看循环内是否注册了大量 defer，再看进程的文件描述符上限；不要先盲目调大系统限制。

先把一次迭代变成一个可收口的函数

推荐将单文件逻辑抽到局部函数。局部函数返回后，里面的 defer 立即执行，因此下一轮开始前，上一轮的句柄已经释放：

func scanFiles(paths []string) error {
	for _, path := range paths {
		// 函数调用形成资源生命周期边界。
		err := func() error {
			f, err := os.Open(path)
			if err != nil {
				return fmt.Errorf("打开 %s: %w", path, err)
			}
			defer func() {
				// 关闭失败也要返回给调用方，不能静默丢弃。
				_ = f.Close()
			}()
			if _, err := io.Copy(io.Discard, f); err != nil {
				return fmt.Errorf("读取 %s: %w", path, err)
			}
			return nil
		}()
		if err != nil {
			return err
		}
	}
	return nil
}

如果文件写入、事务提交或压缩流的 Close 可能报告重要错误，应让局部函数用命名返回值合并关闭错误；读取成功不代表落盘或解码收尾一定成功。

Close 错误、提前返回和大批量任务怎么排查

排查时按三层看：第一层是 os.Open 是否失败；第二层是读取、解码或复制是否提前返回；第三层是 Close 是否被忽略。对只读文件，关闭失败通常不改变已读结果，但它仍可能暴露底层资源或系统异常；对写文件则不能忽略。

可以在压测或批处理监控进程的打开文件数，给输入数量设置合理上限，并确保错误返回路径也会离开局部函数。若任务需要并发处理，限制 worker 数量与每个 worker 的文件生命周期，避免把“及时关闭”变成“同时打开更多”。

常见问题

把 defer f.Close() 改成循环末尾显式 Close 可以吗？

可以，但必须覆盖所有错误和提前返回路径；局部函数加 defer 通常更不容易漏掉清理。

每次循环调用一个普通函数会不会影响性能？

函数边界带来的资源可控性通常比极少量调用开销更重要。确认性能瓶颈后，再用基准测试比较，而不是为了省一次调用牺牲句柄安全。

只读文件是否可以忽略 Close 错误？

简单读取场景下影响可能较小，但统一记录或返回错误更利于发现系统异常；写入、同步和压缩流尤其不能忽略。

记住一个判断句：defer 绑定函数，不绑定循环。看到循环里不断打开文件，就先确认关闭动作的函数边界，再检查错误与并发上限。