Go testing.T Cleanup 怎么登记测试资源清理

Go 测试里只要创建了临时目录、文件、监听器或测试服务器，就应该在资源创建成功后立刻用 t.Cleanup 登记释放函数。它不需要手动调用：当前测试和它的所有子测试结束后，Cleanup 会自动执行；同一个测试中多次登记时，后登记的函数先执行。

先把测试资源交给 t.Cleanup 管理

t.Cleanup(func()) 的参数是一个无参函数。最稳妥的写法是先创建资源，确认没有错误，再立即登记对应的关闭动作。这样即使后面的断言失败，清理责任仍然留在测试框架里，而不是散落在每个返回分支。

func TestConfigFile(t *testing.T) {
	// TempDir 会在测试及其子测试完成后自动移除目录。
	dir := t.TempDir()
	path := filepath.Join(dir, "config.json")

	f, err := os.Create(path)
	if err != nil {
		t.Fatalf("创建测试文件失败: %v", err)
	}
	// 资源创建成功后立即登记关闭动作，避免中途断言失败时遗漏。
	t.Cleanup(func() {
		if err := f.Close(); err != nil {
			t.Logf("关闭测试文件失败: %v", err)
		}
	})

	// 测试主体只关注写入和读取，不再重复安排释放逻辑。
	if _, err := f.WriteString(`{"enabled":true}`); err != nil {
		t.Fatalf("写入配置失败: %v", err)
	}
}

这个例子里，TempDir 自己已经由 testing 负责移除；文件句柄则由我们登记关闭。两种责任不要混成一个“最后清理函数”：谁创建资源，谁就应该在创建点附近说明它的释放方式。

多个 Cleanup 为什么要按后进先出登记

官方文档明确规定，Cleanup 函数按照最后登记、最先调用的顺序执行。这与 Go 的栈式释放习惯一致：如果资源 B 依赖资源 A，就先登记 B 的关闭，再登记 A 的关闭，最终会先释放 B。

func TestStore(t *testing.T) {
	store := openStore()
	// 先登记依赖 store 的会话，保证它先结束。
	session := store.NewSession()
	t.Cleanup(func() {
		// Cleanup 里的错误不能再让测试主体返回，用日志保留线索。
		if err := session.Close(); err != nil {
			t.Logf("关闭会话失败: %v", err)
		}
	})

	// 后登记底层 store，因而它会在 session 之后关闭。
	t.Cleanup(func() {
		if err := store.Close(); err != nil {
			t.Logf("关闭存储失败: %v", err)
		}
	})
}

这里的关键不是把清理代码写到测试末尾，而是安排登记顺序。若把 store 的关闭登记在前、session 登记在后，执行时就可能先关底层存储，再让会话关闭，具体后果取决于库的实现。

子测试的 Cleanup 作用域要单独判断

父测试登记的函数属于父测试作用域；子测试也可以登记自己的清理函数。父测试只有在所有子测试完成后才算完成，因此父级 Cleanup 不应被当作子测试资源的专属释放点。子测试创建的临时文件、连接或模拟服务，最好在子测试内部登记。

func TestCases(t *testing.T) {
	root := newTestRoot()
	// root 被多个子测试共同使用，放在父测试作用域统一关闭。
	t.Cleanup(func() { root.Close() })

	t.Run("invalid-input", func(t *testing.T) {
		fixture := newFixture(root)
		// fixture 只属于当前子测试，不要依赖父级 Cleanup 猜测归属。
		t.Cleanup(func() { fixture.Remove() })
		t.Parallel()
		assertInvalid(t, fixture)
	})
}

如果子测试调用了 t.Parallel()，不要在多个并行分支里修改共享的环境变量、当前工作目录或同一个可变文件。Cleanup 能管理生命周期，却不会自动解决数据竞争；共享资源要么只读，要么在每个子测试中创建独立副本。

常见误区与检查清单

还要注意，Cleanup 函数在测试函数返回后执行，不能把它当成继续调用 t.Fatal 的位置。清理失败通常用 t.Logf 记录，并在资源设计上尽量让关闭动作幂等。对于已经由 TempDir、Setenv 等测试 API 自动托管的资源，不要再写一份可能重复释放的逻辑。

常见问题

Cleanup 和 defer 应该怎么选？

只服务于当前函数、且不涉及子测试时，defer 足够；资源需要覆盖子测试或要统一遵循测试生命周期时，用 t.Cleanup 更清楚。

Cleanup 会按注册顺序执行吗？

不会。多个函数是后进先出，后登记的先执行，登记顺序应按“依赖者先登记、底层资源后登记”安排。

子测试会继承父测试的 Cleanup 吗？

父测试的清理仍属于父作用域，并在父测试及其子测试都完成后执行；子测试自己的资源应由子测试自己登记。

参考：Go testing.T.Cleanup 官方文档。