Go testing.T.SkipNow 后为什么还会执行 t.Cleanup

会执行。testing.T.SkipNow 结束的是当前测试函数后面的正常语句，并不等于跳过测试收尾。它通过 runtime.Goexit 让当前测试 goroutine 离开函数，Go 的收尾机制仍会处理已经登记的 t.Cleanup；只有没有登记、登记时机不对，或资源实际由另一个 goroutine 持有时，才容易看到“跳过后没有清理”的错觉。

SkipNow 停止函数体，但不会跳过测试收尾

先把“停止”拆开看：SkipNow 会把测试标记为 skipped，然后调用 runtime.Goexit。因此它后面的 t.Log、断言和普通清理语句都不会执行；但测试框架仍要把当前测试标记、子测试状态和清理回调收束起来。

这也是 defer 与 Cleanup 容易混淆的地方。defer 绑定当前 Go 函数的退出；Cleanup 绑定 *testing.T 的测试生命周期。测试函数因 SkipNow 结束时，已经登记的 Cleanup 仍然属于这个测试的收尾责任。

用 Cleanup 登记资源，而不是把清理写在 SkipNow 后面

资源一旦创建成功，就应立即登记清理。下面的示例中，SkipNow 后的 t.Fatal 不会运行，但 Cleanup 仍是该测试结束时的收尾入口：

func TestOptionalConfig(t *testing.T) {
	// 资源创建成功后马上登记，避免跳过分支漏掉清理。
	resource := openTestResource()
	t.Cleanup(func() {
		// Cleanup 属于测试生命周期，SkipNow 也不会跳过它。
		resource.Close()
	})

	if !hasLocalConfig() {
		// SkipNow 之后，当前测试函数的普通语句不再继续。
		t.SkipNow()
	}

	// 这条语句不会在 SkipNow 后执行。
	useRequiredConfig(resource)
}

登记顺序也有实际影响。多个 Cleanup 会按后进先出执行，所以外层资源先登记、内层资源后登记时，释放顺序正好可以先关内层再关外层。不要把“跳过”当成“不需要释放资源”，跳过只是测试结论，不是资源所有权的转移。

并行子测试和后台 goroutine 是另一条边界

Cleanup 的归属跟着 *testing.T 走。子测试注册的回调属于子测试；父测试的回调要等父测试及其子测试完成后再收尾。并行子测试还会延后父测试继续收尾的时机，因此不要用一条日志的先后顺序推断所有回调的生命周期。

另一个常见误判来自后台 goroutine。官方语义明确指出，SkipNow 只能从运行测试函数的 goroutine 调用，而且不会停止测试期间创建的其他 goroutine。若后台任务持有连接、临时文件或 channel，它需要自己的取消信号和退出确认；父测试的 Cleanup 只能负责发出关闭动作或等待它结束，不能凭空替代 goroutine 的生命周期管理。

跳过用例的复查清单

遇到“SkipNow 后资源没有释放”的问题，可以按下面的顺序复查。第一，看资源创建和 t.Cleanup 登记是否在同一条成功路径上；第二，看清理回调是否注册到了正确层级的 *testing.T；第三，看资源是否被后台 goroutine 转移或继续使用；第四，看 Cleanup 内部是否又依赖了一个已经被跳过的条件。

判断结果时不要只看测试显示为 SKIP。更可靠的结论是：函数体在 SkipNow 处停止，已登记的测试收尾仍有责任执行，后台 goroutine 则必须按自己的退出协议完成。这个拆分比给 SkipNow 追加一段“补偿清理”更稳定。

常见问题

SkipNow 后的 defer 还会执行吗？

当前函数已经通过 Goexit 离开时，Go 的 defer 机制会参与函数退出；但清理测试资源更推荐使用 t.Cleanup，因为它表达的是测试生命周期，而不是某个局部函数的退出路径。

Cleanup 里的断言失败会把跳过改成失败吗？

Cleanup 仍在测试收尾阶段运行，里面的错误报告会影响最终测试结果。不要在清理回调里依赖“这个测试一定没有跳过”的状态，必要时把释放失败记录成明确的诊断信息。

从 goroutine 里调用 SkipNow 可以吗？

不可以。SkipNow 必须由运行测试函数的 goroutine 调用；后台 goroutine 应通过 channel 或 context 把结果交回测试 goroutine，再由测试函数决定跳过、失败或继续。