Go 问答：defer 为什么不适合直接放在大循环里，资源该怎么释放

很多 Go 初学者喜欢看到资源打开后立刻写一句 defer Close()，这个习惯本身很好：就近登记清理动作，代码读起来也安心。但如果把这句 defer 直接写在一个大循环里，资源并不会在每一轮循环结束时释放，而是会等到当前函数返回前才统一释放。

这篇 Go 问答用文件读取场景讲清楚三个问题：defer 到底什么时候运行，为什么循环里容易积压资源，以及生产代码里应该怎样改写。

摘要

defer 绑定的是当前函数作用域，不是循环作用域。循环里反复打开文件、连接或加锁时，如果每轮都登记 defer，清理动作会排队到函数快返回时才依次运行。解决思路是把单轮逻辑拆成小函数，或者在本轮处理完成后显式关闭资源，并认真处理关闭错误。

适合人群

适合正在学习 Go 基础语法、文件处理、数据库连接、锁使用和错误处理的开发者。你只需要理解 for 循环、函数返回值和 error 即可阅读。

目录

1. 一句话回答
2. 先看一个容易出事的写法
3. defer 的三个关键规则
4. 改法一：拆成小函数
5. 改法二：本轮结束后显式关闭
6. 锁、事务和网络连接也会遇到同类问题
7. 排查清单和总结

一、一句话回答

问题：为什么 defer 不适合直接放在大循环里？

因为 defer 登记的清理动作会等当前函数返回前才运行。循环有一万轮，就可能登记一万个延迟清理动作；如果每轮都打开文件、网络连接或占用锁，这些资源会在函数结束前一直被占着。

二、先看一个容易出事的写法

下面这段代码看起来很自然：每打开一个文件，就写 defer f.Close()。问题是 badReadFiles 没返回之前，所有打开过的文件都会继续占用句柄。

package main

import (
	"bufio"
	"fmt"
	"os"
)

func badReadFiles(paths []string) error {
	for _, path := range paths {
		f, err := os.Open(path)
		if err != nil {
			return err
		}
		defer f.Close()

		scanner := bufio.NewScanner(f)
		for scanner.Scan() {
			// 处理每一行
		}
		if err := scanner.Err(); err != nil {
			return err
		}
		fmt.Println("done:", path)
	}
	return nil
}

如果文件数量很少，这段代码可能长期没暴露问题；一旦路径列表很大，就可能遇到“too many open files”、连接池被占满、锁长时间不释放等问题。

三、defer 的三个关键规则

1. 绑定当前函数，不绑定循环

defer 的清理动作在当前函数返回前运行。for、if、switch 这些代码块结束，并不会触发它。

2. 参数在登记时就确定

调用 defer f.Close() 时，f 这个接收者已经确定了。后面循环变量怎么变化，不影响已经登记的清理动作。

3. 后登记的先运行

一个函数里有多个 defer 时，最后登记的会先运行。这对释放栈式资源很有用，但在大循环里也意味着清理动作会越积越多。

四、改法一：拆成小函数

最推荐的方式是把“处理一个文件”的逻辑拆成单独函数。这样每一轮循环都会调用小函数，小函数返回时，对应的 defer 就会运行。

func readOneFile(path string) error {
	f, err := os.Open(path)
	if err != nil {
		return err
	}
	defer f.Close()

	scanner := bufio.NewScanner(f)
	for scanner.Scan() {
		// 处理每一行
	}
	return scanner.Err()
}

func goodReadFiles(paths []string) error {
	for _, path := range paths {
		if err := readOneFile(path); err != nil {
			return fmt.Errorf("read %s: %w", path, err)
		}
		fmt.Println("done:", path)
	}
	return nil
}

这个写法的好处是边界清楚：一个函数负责一个文件，一次打开对应一次释放。它也更方便单元测试，出错时能给出具体路径。

五、改法二：本轮结束后显式关闭

有些场景不方便拆函数，也可以在本轮逻辑结束后显式关闭资源。注意不要只写 f.Close() 然后忽略错误，尤其是写文件、刷缓冲区、网络写入这类场景。

func readFilesWithClose(paths []string) error {
	for _, path := range paths {
		f, err := os.Open(path)
		if err != nil {
			return err
		}

		scanner := bufio.NewScanner(f)
		for scanner.Scan() {
			// 处理每一行
		}
		scanErr := scanner.Err()
		closeErr := f.Close()

		if scanErr != nil {
			return fmt.Errorf("scan %s: %w", path, scanErr)
		}
		if closeErr != nil {
			return fmt.Errorf("close %s: %w", path, closeErr)
		}
	}
	return nil
}

显式关闭的优点是资源释放时机非常直观；缺点是错误路径多了以后容易漏写关闭逻辑。因此，只要业务允许，仍然建议优先拆小函数。

六、锁、事务和网络连接也会遇到同类问题

这个问题不只发生在文件句柄上。下面这些资源也很常见：

• 循环里 mu.Lock() 后写 defer mu.Unlock()，会导致锁到函数返回前才释放。
• 循环里开启数据库事务后 defer tx.Rollback()，可能让事务堆积过久。
• 循环里获取连接后 defer conn.Close()，可能把连接池占满。
• 循环里创建临时文件后延迟删除，磁盘空间可能短时间内上涨。

判断标准很简单：如果资源只应该服务于本轮循环，就不要让它活到整个函数结束。

七、排查清单和总结

排查清单

• 在大循环里搜索 defer，看它清理的是不是文件、连接、锁、事务或临时目录。
• 确认资源生命周期：它服务于整段函数，还是只服务于单轮循环。
• 如果只服务于单轮循环，优先拆成小函数。
• 如果必须显式关闭，把主流程错误和关闭错误都处理掉。
• 压测时观察文件句柄、连接池占用、锁等待和磁盘临时文件数量。

总结

defer 是 Go 里非常好用的清理机制，但它跟随函数作用域，而不是循环作用域。小函数里用 defer 往往清晰又安全；大循环里直接登记资源清理，就可能把释放时机拖得太晚。记住一句话：资源属于哪一层作用域，清理动作就应该放在哪一层作用域。

参考资料

本文基于 Go 官方文档和 Go 官方博客中关于 defer 语义的说明，结合文件句柄、锁和连接池场景整理为原创问答。