Go testing.T Cleanup按注册逆序释放测试资源的组织方法

Go 测试里，testing.T.Cleanup 的关键规则是“后注册、先执行”。每当一个资源创建成功，就在同一测试作用域里立即登记对应的释放函数；多个资源按依赖顺序登记后，Cleanup 会自然形成逆序释放链。这样即使断言失败，文件、客户端、临时状态也不会因为提前返回而漏掉清理。

按资源依赖关系设计注册顺序

官方 testing 文档把 Cleanup 定义为测试（或子测试）及其全部子测试完成时调用的函数，并明确采用 last added, first called。可以把它看成一摞按作用域保存的释放回调，而不是普通的“测试结束通知”。

例如测试先创建连接池，再创建依赖该连接池的仓储对象，登记顺序应保持一致：

func TestRepository(t *testing.T) {
	pool := newPool()
	t.Cleanup(func() {
		// 先释放最外层连接资源，关闭动作应保持可重复调用。
		_ = pool.Close()
	})

	repo := newRepository(pool)
	t.Cleanup(func() {
		// 后注册的仓储依赖先收尾，再轮到连接池。
		_ = repo.Close()
	})

	// 这里的断言只使用已经准备好的 repo。
	_ = repo
}

上例最终先执行 repo.Close，再执行 pool.Close。表格可以帮助快速判断注册位置：

获取成功后立即登记清理函数

不要把所有关闭动作集中写在测试末尾。集中清理容易被中途的 t.Fatal、返回分支或新增断言打断。更稳妥的方式是让“取得资源”和“登记所有权”紧挨着出现：

func TestConfigFile(t *testing.T) {
	f, err := os.Open("testdata/config.json")
	if err != nil {
		t.Fatal(err)
	}
	t.Cleanup(func() {
		// 关闭错误写入测试日志，避免静默丢失资源问题。
		if err := f.Close(); err != nil {
			t.Logf("close config: %v", err)
		}
	})

	// 下面的校验即使失败，已经登记的关闭函数仍会执行。
	_ = f
}

闭包应捕获已经确认有效的句柄；打开失败时不要登记一个无效资源。清理函数适合做关闭、回滚、恢复环境变量等收尾动作，不宜承载新的业务断言，也不宜依赖另一个可能已经被更早清掉的资源。

用子测试隔离局部资源

如果资源只服务一个场景，应放进对应的 t.Run。这样资源的所有权、登记位置和释放边界都在一个函数里，多个子测试不会共享一份容易被提前关闭的状态：

func TestCases(t *testing.T) {
	t.Run("isolated snapshot", func(t *testing.T) {
		snapshot := createSnapshot()
		t.Cleanup(func() {
			// 子测试结束时删除自己的快照，不影响兄弟场景。
			if err := snapshot.Remove(); err != nil {
				t.Logf("remove snapshot: %v", err)
			}
		})
		// 只在这个子测试中使用 snapshot。
		_ = snapshot
	})
}

父测试级资源可以供多个子测试共用，但必须确认它的清理函数不会早于子测试所需的依赖。局部资源则优先局部注册，减少共享状态和清理顺序的推理成本。

处理清理错误并复核释放链

Cleanup 的执行顺序解决了资源依赖问题，但不会替你决定错误策略。关闭文件、回滚快照这类动作如果失败，应使用 t.Logf 留下上下文；不要在清理阶段启动新的复杂流程，也不要让同一个句柄既由测试主体关闭、又由 Cleanup 无条件关闭。确实需要提前关闭时，应让关闭函数具备幂等性，或把“提前关闭”与“登记的最终释放”统一到一个所有权函数中。

发布前可用下面的清单复核：资源是否在成功获取后立即登记；注册顺序是否与依赖相反；子测试资源是否局部持有；Cleanup 是否只做收尾；清理失败是否有日志；断言失败、t.Fatal 和子测试退出时是否仍有明确释放路径。

相关问题

Cleanup 和 defer 应该怎么选？

只需要当前函数返回时释放时，defer 足够；需要绑定测试作用域、覆盖测试失败路径或子测试边界时，优先使用 t.Cleanup。

Cleanup 会按注册顺序执行吗？

不会。官方规则是后注册先执行，因此依赖资源应先登记，被依赖对象应后登记。

能在 Cleanup 里继续做测试断言吗？

不建议。Cleanup 的职责是释放和恢复；若必须报告问题，保留带资源名称的日志，把主要断言放在测试主体内。