Go t.Cleanup登记资源释放动作的测试结构

Go 测试里的临时目录、监听器、数据库连接和环境变量，最容易在“创建成功之后、断言失败之前”留下清理缺口。更稳的结构是：资源创建函数在返回资源的同时，用 t.Cleanup 把释放动作登记到当前测试；调用方拿到资源就可以继续写断言，不必在每个分支里补一套清理。

把资源创建与 t.Cleanup 登记放在同一个辅助函数

testing.T.Cleanup 从 Go 1.14 起可用。它接收一个无参数函数，在测试或子测试以及其全部子测试结束后执行。最实用的落点是资源工厂：成功创建后立即登记释放动作，避免调用方在多个 return、Fatal 或错误分支中遗漏清理。

func newWorkspace(t *testing.T) string {
	// Helper 让失败位置更接近真正调用 newWorkspace 的测试。
	t.Helper()
	dir := t.TempDir()
	marker := filepath.Join(dir, "ready.txt")
	if err := os.WriteFile(marker, []byte("ready"), 0o600); err != nil {
		// 创建后的资源由 Cleanup 负责回收，失败只报告当前测试。
		t.Fatalf("写入测试文件失败: %v", err)
	}
	t.Cleanup(func() {
		// 清理动作允许重复执行，便于辅助函数组合使用。
		_ = os.Remove(marker)
	})
	return dir
}

这里的关键不是把删除代码写进函数，而是把“谁创建、谁登记”绑定起来。TempDir 本身也会在测试及其子测试完成后自动删除目录；示例中的文件清理用于说明自定义资源的相同组织方式。若资源创建失败，应直接让测试终止，不要登记一个指向未初始化句柄的清理函数。

用后进先出的顺序组织多个清理动作

官方文档规定，清理函数按最后登记、最先调用的顺序执行。可以把它理解成一摞依赖关系：先准备的外层环境最后撤销，后创建的内层对象先释放。下面的顺序适合“先开服务，再创建客户端”的测试。

func TestStore(t *testing.T) {
	server := startTestServer(t)
	t.Cleanup(func() {
		// 先登记的服务在最后关闭，保证客户端仍能完成释放。
		server.Close()
	})

	client := newStoreClient(t, server.URL)
	t.Cleanup(func() {
		// 后登记的客户端先关闭，遵守依赖的逆序释放。
		if err := client.Close(); err != nil {
			t.Logf("关闭测试客户端失败: %v", err)
		}
	})

	// 这里直接写断言；失败或 Fatal 都不会跳过已登记的清理。
	if got := client.Ping(); got != nil {
		t.Fatalf("Ping 失败: %v", got)
	}
}

如果客户端关闭动作还需要访问服务端，客户端必须后登记；否则服务端先关，清理阶段会把真正的资源错误伪装成连接错误。对于没有依赖关系的临时文件和计数器，顺序不重要，但统一按创建逆序登记仍更容易读。

区分父测试、子测试和提前失败的生命周期

登记给哪个 *testing.T，就决定资源的生命周期。登记在父测试上的清理会等父测试和所有子测试都完成；登记在子测试上的清理会在该子测试及其后代结束时执行。因此，共享连接或服务应放在父层，某个案例专用的临时状态应放在子测试内部。

func TestImport(t *testing.T) {
	shared := openFixture(t)
	t.Cleanup(func() {
		// 父级资源留到全部子测试完成后再关闭。
		_ = shared.Close()
	})

	for _, name := range []string{"empty", "duplicate"} {
		t.Run(name, func(t *testing.T) {
			local := newCaseState(t)
			t.Cleanup(func() {
				// 案例状态只属于当前子测试，结束后立即释放。
				_ = local.Close()
			})
			checkImport(t, shared, local)
		})
	}
}

Fatal 和 FailNow 会结束当前测试函数，但不会绕过已经登记的 Cleanup。需要注意的是，另一个 goroutine 中调用 FailNow 本身是不合法的；并发测试也不能把仍会被其他 goroutine 使用的共享资源过早关闭。清理边界首先由 t.Run 的层级决定，其次才是代码出现的先后位置。

为清理函数补上幂等和失败记录策略

清理代码通常不应再次触发主测试断言。关闭函数可能返回错误，但 Cleanup 阶段的首要任务是尽量释放剩余资源，并保留失败上下文。对可能被底层库自动关闭的对象，优先调用幂等 API，或使用一次性保护；对无法忽略的错误，用 t.Logf 记录资源名、测试名和阶段。

不要在 Cleanup 中调用 t.Fatal 作为普通错误处理。这样会把资源释放问题提升为新的终止信号，反而让原本的业务断言更难定位。若释放失败需要让 CI 感知，可在清理前把状态写入测试日志，或由专门的资源封装统一汇总。

用清单检查测试资源的登记位置

• 创建成功后是否立刻登记，且清理函数捕获的是已经初始化的资源。
• 多个资源是否按依赖逆序释放，客户端没有早于服务端关闭。
• 共享资源是否登记在父测试，案例资源是否登记在对应子测试。
• 清理动作是否可以重复调用，错误是否带有资源上下文而不是覆盖主断言。
• 并发测试是否避免在仍有 goroutine 使用资源时结束父层生命周期。

把这些判断落实到资源工厂和测试层级后，测试主体就只负责准备输入、调用目标代码和断言结果。资源释放不再依赖“每条路径都记得写 defer”，而是成为创建动作的一部分。

常见问题

t.Cleanup 和 defer 应该怎么选？

defer 适合当前函数的局部控制流；测试资源需要覆盖 Fatal、子测试和辅助函数时，t.Cleanup 更能表达测试生命周期。

多个 Cleanup 的执行顺序固定吗？

固定为后登记先执行。如果资源之间存在依赖，就按创建顺序登记，释放时自然得到逆序。

子测试能使用父测试登记的资源吗？

可以，前提是父资源在全部子测试完成前保持有效；子测试自己的资源应登记给子测试的 t，不要误绑到父层。