Go t.Cleanup 为什么注册顺序决定释放顺序

我第一次把多个资源都交给 t.Cleanup 时，最容易犯的错是按注册代码的上下顺序猜释放顺序。实际上，Go 官方文档规定：Cleanup 会在测试（或子测试）及其所有子测试结束后调用，并且遵循“后注册、先调用”。所以，后面注册的函数会先拿到清理机会，整体行为和栈的后进先出一致。

同一个 *testing.T 上，t.Cleanup 的注册顺序决定清理栈的出栈顺序；父测试和子测试则按各自作用域结束，不能把它们混成一条全局队列。

• 同一作用域：先注册 A、再注册 B，调用顺序是 B、A。
• 子测试边界：子测试自己的清理函数随子测试结束，父测试的清理函数要等所有子测试完成。
• 资源原则：谁创建资源，谁在同一测试作用域注册对应的清理动作。

Cleanup 的顺序为什么是后注册先调用

t.Cleanup 的目的不是在每一行代码后立刻执行释放，而是把清理函数登记到当前测试的清理集合中。官方文档直接说明调用顺序为 last added, first called；Go 源码中的 Cleanup 方法也会把包装后的函数追加到当前对象的 cleanup 列表。因此，登记动作类似向栈顶压入一个函数，测试作用域结束时再从最近登记的函数开始处理。

用一个最小测试预测调用次序

下面的例子只验证顺序，不依赖真实文件或数据库。先登记连接，再登记临时目录，阅读结果时不要把注册顺序当成调用顺序：

func TestCleanupOrder(t *testing.T) {
	// 连接是较早创建的资源，先登记它的释放动作。
	t.Cleanup(func() {
		t.Log("close connection")
	})

	// 临时目录后登记，因此它位于清理栈更靠上的位置。
	t.Cleanup(func() {
		t.Log("remove temp dir")
	})
}

// 预期的清理日志顺序：
// remove temp dir
// close connection

这里的关键不是日志文本，而是栈关系：第二次 Cleanup 注册的函数先调用。若临时目录中的文件依赖连接仍可用，就要重新检查资源之间的依赖关系；通常更稳妥的做法是让依赖者先登记，拥有者后登记，或者把相关清理封装到同一个函数中。

父测试和子测试不是同一个清理栈

官方定义还包含“测试及其所有子测试完成后”这一边界。子测试注册的清理动作属于子测试作用域；父测试注册的清理动作属于父测试作用域。父级清理不会在某个子测试刚结束时提前执行，它要等父测试的子测试全部完成。

func TestParent(t *testing.T) {
	// 这个清理动作属于父测试，不能在子测试结束时单独触发。
	t.Cleanup(func() {
		t.Log("parent resource released")
	})

	t.Run("child", func(t *testing.T) {
		// 子测试资源应在子测试作用域登记，避免生命周期放大到父测试。
		t.Cleanup(func() {
			t.Log("child resource released")
		})
	})
}

资源边界可以这样判断：只被子测试使用的资源，在子测试中创建和登记；多个子测试共享的资源，放在父测试中创建并登记。这样即使测试增加新的子场景，也不需要手工拼接释放顺序。

它和 defer 的区别在哪里

defer 绑定的是当前函数返回，t.Cleanup 绑定的是当前测试或子测试作用域完成。测试函数中直接写的 defer 会在测试函数返回时执行；如果测试内部还要运行子测试，就不应把“必须等所有子测试结束”的父级资源误写成某个更窄函数里的 defer。

排查 Cleanup 顺序时先看这三点

1. 确认清理函数是不是在同一个 *testing.T 上注册；不同子测试对象不能按一个列表推断。
2. 把注册动作按时间写成一列，再从最后一项向前读，先排除“代码位置顺序等于执行顺序”的误判。
3. 检查资源依赖：外层资源应晚于依赖它的内层资源登记，确保依赖者先清理。

Go t.Cleanup 常见问题

注册两次 Cleanup 会覆盖前一次吗？

不会。每次调用都会登记一个清理函数；在同一作用域内，它们按后注册先调用。

子测试结束后父测试的 Cleanup 会马上执行吗？

不会。子测试自己的清理先受子测试作用域管理，父测试的清理要等父测试及其所有子测试完成。

怎么让数据库连接和临时文件按正确顺序释放？

先画出资源依赖，再按“希望谁先释放”倒序注册。如果临时文件清理依赖连接，先登记连接、后登记临时文件，让临时文件清理先发生。

记住一句话就够了：t.Cleanup 不是按注册顺序排队执行，而是把清理函数放进当前测试作用域的栈；同一作用域后注册先调用，父子测试则各自遵守生命周期边界。