Go t.Cleanup注册后测试提前Fatal的资源释放边界

Go 测试在资源准备完成后调用 t.Fatal，并不意味着已经注册的清理逻辑会被跳过。t.Cleanup 由 testing 挂在当前测试边界上，测试函数因 FailNow 提前结束后，清理仍会在该测试及其子测试完成时执行。真正需要警惕的是资源归属和 goroutine 归属：后台 goroutine 不能直接用 t.Fatal 结束测试，父测试也不应替子测试管理所有资源。官方文档可复制查看：https://pkg.go.dev/testing。

提前 Fatal 时，Cleanup 到底在哪个边界执行

t.Fatal 等价于记录日志后调用 FailNow。FailNow 通过 runtime.Goexit 结束当前测试函数的执行路径，因此后面的普通语句不会再运行；但 testing 仍会收束当前测试的生命周期，并调用已经注册的清理函数。清理不是依赖“代码顺序走到函数末尾”，而是依赖测试框架保存的清理栈。

这意味着下面的资源会被释放：临时目录、测试数据库连接、临时配置和 mock 服务等，只要它们是在失败发生前通过当前 *testing.T 注册的。没有注册、注册晚于 Fatal，或者由后台 goroutine 私自创建的资源，则不在这个保证范围内。

资源创建后立即注册，顺序按后进先出处理

最稳妥的习惯是“创建一项，马上注册一项”。清理函数按后注册先执行，正好适合先关闭依赖对象、再关闭被依赖对象。例如 reader 依赖连接，应该先清 reader，再关闭连接。

func TestImportFailureCleanup(t *testing.T) {
	// 资源创建成功后立即登记清理，后续 Fatal 也不会漏掉它。
	conn, err := openTestConn()
	if err != nil {
		t.Fatal(err)
	}
	t.Cleanup(func() {
		// 关闭动作应当幂等，便于失败路径和测试辅助函数复用。
		_ = conn.Close()
	})

	reader, err := newImportReader(conn)
	if err != nil {
		t.Fatal(err)
	}
	t.Cleanup(func() {
		// reader 依赖 conn，因此按后进先出先释放 reader。
		_ = reader.Close()
	})

	if err := reader.Prepare(); err != nil {
		// 这里提前失败，但上面两项 Cleanup 仍属于当前测试边界。
		t.Fatalf("prepare import: %v", err)
	}
}

这个示例的关键不是把 Fatal 换成返回值，而是让每个成功创建的资源都有一条已经落入 testing 清理栈的释放路径。若 newImportReader 失败，连接仍会被关闭；若 Prepare 失败，reader 先关闭，连接后关闭。

子测试要让资源跟着拥有它的边界走

t.Run 会形成独立的子测试边界。子测试注册的 t.Cleanup 应在子测试及其子孙测试结束后执行；父测试的清理则要等自己的子测试全部完成。把子测试专用连接注册到父测试，容易出现子测试已经结束但资源还被父级持有的问题，也会让并行组织更难判断。

func TestReaders(t *testing.T) {
	// 父级只准备所有用例都共享的只读配置。
	settings := loadTestSettings()

	for _, name := range []string{"orders", "refunds"} {
		name := name // 为闭包固定当前用例名。
		t.Run(name, func(t *testing.T) {
			// 子测试自己的连接由子测试负责关闭。
			reader, err := openReader(settings, name)
			if err != nil {
				t.Fatalf("open %s: %v", name, err)
			}
			t.Cleanup(func() {
				// 子测试提前 Fatal 时，这个清理仍在本边界内执行。
				_ = reader.Close()
			})

			if err := reader.Check(); err != nil {
				t.Fatalf("check %s: %v", name, err)
			}
		})
	}
}

如果父级本身注册了清理，它不会因为某个子测试 Fatal 就立即执行；父级要等所有子测试结束。这个层级关系适合“父级共享配置、子级独占资源”的测试结构。父级资源若被子级使用，就要确保父级清理不会早于所有子级完成。

异步 goroutine 出错时不要直接调用 Fatal

官方文档明确要求 FailNow 必须由运行测试函数的 goroutine 调用；它不会停止测试创建的其他 goroutine。因此后台任务里直接写 t.Fatal，即使看起来“失败了”，也可能只结束了后台 goroutine，测试主体仍继续执行，甚至在资源已被清理后继续访问它。

func TestAsyncImport(t *testing.T) {
	// 用带缓冲 channel 回传一次错误，避免测试主体等待时发生阻塞。
	errCh := make(chan error, 1)
	done := make(chan struct{})
	t.Cleanup(func() {
		// 先通知后台任务停止，再等待它退出，避免清理后仍访问资源。
		close(done)
	})

	go func() {
		// 后台 goroutine 只回传错误，不直接调用 t.Fatal。
		if err := runImport(done); err != nil {
			errCh 

实际项目还要让成功路径写入完成信号，并在测试主体等待“成功或错误”二者之一；上面只突出错误归属。清理函数若需要等待后台任务，应使用明确的 WaitGroup 或完成通道，不能只关闭停止信号就假定 goroutine 已经退出。

提交前用四项清单检查提前失败路径

排查时可以先缩小测试范围：go test -run TestImportFailureCleanup -count=1；涉及并发清理时再使用 go test -race ./...。这些命令用于检查测试组织，不能替代资源所有权设计。

相关问题

提前调用 t.Fatal 会跳过 t.Cleanup 吗？

不会。只要 Cleanup 已经注册，并且属于当前测试边界，测试提前失败后仍会由 testing 在边界结束时调用。

多个 t.Cleanup 的执行顺序是什么？

后注册的先执行。可以把它理解为一组栈式释放动作，资源依赖关系应反映在注册顺序上。

后台 goroutine 能不能调用 t.Fatal？

不应这样做。后台 goroutine 应通过 channel 等方式回传错误，再由运行测试函数的 goroutine 调用 Fatal；同时还要等待后台任务退出。