Go testing.T.Cleanup 多次注册时为什么按逆序执行

我在给集成测试补夹具时，最容易忽略的不是资源创建，而是资源销毁的依赖关系：临时服务还没停，数据库连接池已经被关掉；或者多个清理函数都注册了，却发现最后注册的那个先执行。Go 的 testing.T.Cleanup 不是按照注册顺序排队，而是遵循“后注册、先执行”（LIFO）规则。

官方文档地址：https://pkg.go.dev/testing#T.Cleanup

这条规则本身很简单，但放进父测试、子测试和并行测试后，资源归属就需要明确。本文只讨论 testing.T.Cleanup 的注册与执行顺序，不把它和测试框架外的 defer 组合混在一起。

我第一次遇到的顺序问题

假设一个测试先准备数据库连接，再启动依赖数据库的测试服务。收尾时，服务应该先停止，连接池最后关闭。若按创建顺序直接注册回调，代码看起来很自然，却得到相反的收尾顺序：

package cleanup_test

import (
	"fmt"
	"testing"
)

func TestCleanupOrder(t *testing.T) {
	// 先创建底层资源，再创建依赖它的上层资源。
	dbReady := true
	t.Cleanup(func() {
		// 数据库必须留到依赖它的服务停止之后。
		dbReady = false
		fmt.Println("close database")
	})

	t.Cleanup(func() {
		// 后注册的回调会先执行，所以服务先于数据库收尾。
		if !dbReady {
			t.Error("database was closed before service")
		}
		fmt.Println("stop service")
	})
}

这里的第二个 Cleanup 后注册，因此它先执行。只要把“依赖者先清理、被依赖者后清理”映射到注册顺序，写法就不容易反过来：底层资源先注册，依赖它的资源后注册。

把 Cleanup 看成当前测试作用域的一座栈

每调用一次 t.Cleanup(f)，都相当于把一个回调压入当前测试作用域的清理栈。测试或子测试完成时，从栈顶向栈底取出回调，所以最后注册的函数最先运行。

这和普通函数体里的 defer 有相同的后进先出直觉，但两者的触发边界不同：Cleanup 由测试作用域结束触发，且会等待该测试的子测试完成；不要因为它们都表现为逆序，就把不同作用域的行为当成一条共享栈。

子测试怎样划分清理责任

子测试是我后来用来降低混乱的边界。父测试负责共享资源，子测试负责自己的临时资源。t.Run 的子测试及其后代完成后，子测试作用域中的清理函数会执行；父测试的清理要等所有子测试完成后才执行。

func TestSubtestCleanup(t *testing.T) {
	// 父测试拥有共享资源，子测试完成后再关闭它。
	shared := "shared-fixture"
	t.Cleanup(func() {
		fmt.Println("release", shared)
	})

	t.Run("case-a", func(t *testing.T) {
		// 子测试只登记自己创建的临时对象。
		local := "case-a-temp"
		t.Cleanup(func() {
			fmt.Println("remove", local)
		})
		fmt.Println("run", local)
	})
}

这种写法的重点是“谁创建，谁登记清理”。如果子测试把父测试的共享连接提前关闭，另一个子测试就可能读到失效资源；如果父测试替子测试登记所有清理，又很难看出资源到底属于哪一层。

用一个最小日志检查顺序

遇到“清理太早”时，我会先让回调写出短日志，再从回调归属和注册位置倒推问题。下面的例子刻意注册两个回调，方便观察逆序：

func TestLogCleanup(t *testing.T) {
	// 用日志记录回调名，不把日志顺序当成跨并行测试的全局时序。
	t.Cleanup(func() { fmt.Println("cleanup: first registration") })
	t.Cleanup(func() { fmt.Println("cleanup: second registration") })
}

=== RUN   TestLogCleanup
--- PASS: TestLogCleanup (0.00s)
cleanup: second registration
cleanup: first registration

真实项目里不必长期保留打印。确认顺序后，可以把日志替换为带错误处理的关闭函数，并让每个回调只处理自己的资源。不要依赖多个并行子测试的输出顺序；并行测试的重点是作用域完成和资源隔离，而不是让日志呈现出一条固定时间线。

几个容易写反的边界

• 资源依赖决定注册顺序。先创建的底层资源通常先注册清理，后创建的依赖资源后注册清理，这样执行时依赖资源先退出。
• 回调属于注册它的测试。不要把子测试的临时目录、端口或模拟服务混进父测试的统一清理函数。
• 子测试完成是父测试清理的前提。父级共享资源不能在子测试仍会使用时提前释放。
• 失败也要保证清理函数可安全重复收尾。关闭函数应处理已关闭、创建失败和部分初始化等状态，避免清理阶段再次让测试进程异常。
• 并行只解决调度，不改变局部 LIFO 规则。每个测试作用域仍按后注册先执行，但不同并行作用域之间不要建立顺序依赖。

我的结论：先画资源关系，再写 Cleanup

testing.T.Cleanup 多次注册时按逆序执行，是为了让后建立的上层资源先退出，给底层资源留下完整的依赖环境。最稳妥的习惯是：先列出资源依赖图，按底层到上层的创建顺序注册清理；再用子测试作用域收拢局部资源；最后用一次短日志确认实际归属。

如果只记一个判断方法，可以问自己一句：“这个回调执行时，它依赖的对象还在吗？”若答案是否定的，就把依赖对象的 Cleanup 提前注册，让它在栈底更晚执行。

相关问题

Cleanup 和 defer 可以同时使用吗？

可以，但它们的生命周期不同。defer 绑定当前 Go 函数返回，Cleanup 绑定测试或子测试作用域结束。混用时应分别画出触发边界，不能只按一个逆序列表推断。

子测试失败后 Cleanup 还会执行吗？

测试清理的设计目标就是在测试或子测试结束时执行已登记回调，因此清理函数应按“测试可能失败”来编写：检查关闭错误、允许部分初始化，并避免依赖测试主体最后一次断言一定成功。

为什么不把所有清理都注册在父测试里？

父测试可以管理共享资源，但局部资源放在子测试里更容易保证生命周期匹配，也能减少并行子测试之间的隐式依赖。只有确实跨多个子测试共享的对象，才适合由父测试统一管理。