Go 1.25 用 testing.T.Context 让测试超时自动传递：清理顺序与失败定位

测试里最容易被忽略的一类后台任务，是测试函数已经返回，goroutine 却还在等资源。Go 的 testing.T.Context 正好提供了一条和测试生命周期绑定的取消链：它返回的上下文会在测试的 Cleanup 函数执行前被取消。把这条信号传给 worker，超时、主动失败和资源回收就能落到同一条路径上。

把 t.Context() 当作测试范围的父上下文使用；需要在 Cleanup 中等待退出的资源，应监听它的 Done，但不要把“收到取消”误认为业务操作已经成功。

先看一个真实的测试生命周期

假设测试启动一个后台 worker，它持续处理队列，测试结束时要等它关闭。关键点不是“创建一个 context”这么简单，而是取消发生在什么时间：t.Context() 被取消后，注册的 t.Cleanup 才开始执行。Cleanup 可以等待 worker 退出，这正是它和普通请求上下文的差别。

func TestWorkerStopsWithTest(t *testing.T) {
	ctx := t.Context()
	done := make(chan struct{})

	go worker(ctx, done)
	t.Cleanup(func() {
		

这段代码里的节点关系很短：testing.T.Context 产生 ctx，worker 等待 ctx.Done，收到取消后关闭 done，最后 t.Cleanup 等待这个信号。图中的连线只表达这条实际调用和状态路径。

把取消信号传进 worker，而不是在测试里另起一条生命周期

如果 worker 内部重新调用 context.Background()，它就和测试脱钩了；测试超时后，worker 仍可能阻塞。正确做法是把 t.Context() 作为父上下文传入，并在 worker 的循环里优先处理 ctx.Done。

func worker(ctx context.Context, jobs 

这里的可见成功状态是：测试结束或超时后，ctx.Done 被选中，worker 返回，done 关闭，Cleanup 的接收操作能够继续。不要只在测试主体里调用取消函数，然后让 worker 继续使用另一个 context。

Cleanup 顺序决定了资源是否真的收干净

t.Context() 的语义是“在 Cleanup 注册函数被调用前取消”。因此 Cleanup 中可以等待依赖这个取消信号的 goroutine。多个 Cleanup 按后注册先执行；如果一个 Cleanup 负责关闭输入，另一个 Cleanup 负责等待 worker，就要按依赖关系安排注册顺序，并在代码旁写清谁等待谁。

一个常见误区是把 t.Cleanup 当作取消函数。它不是。取消由 t.Context 的生命周期触发，Cleanup 负责在取消之后释放或等待资源。把两者混在一起，失败时很难判断到底是 worker 没退出，还是测试提前结束。

测试超时和业务失败要分开记录

当测试设置了超时，ctx.Done 被触发只说明测试生命周期结束信号已经到达。worker 若还有未提交任务，应记录“取消中止”，而不是把它改写成“任务成功”。在测试里可以用独立错误通道接收业务错误，再在主体断言；Cleanup 只做关闭和等待。

errCh := make(chan error, 1)
go func() {
	select {
	case errCh 

这个例子还提醒一件事：不要重复创建多个派生 context 来猜测测试状态。需要超时的是业务操作，可以从 t.Context() 派生；需要等待清理的是 worker，则直接监听同一个父上下文。

兼容旧版本时保留显式取消方案

官方文档把 testing.T.Context 标为 Go 1.24 起提供。项目如果仍支持更早的 Go 版本，不能仅凭本机编译通过就直接替换。可以先确认 go.mod 的 go 版本和 CI 镜像，再决定是否迁移；旧版本继续使用 context.WithCancel，升级后再把取消点交给测试生命周期。

• 先用 CI 中声明的最低 Go 版本执行 go test ./...。
• 检查所有 worker 是否监听同一条取消链。
• 故意触发测试超时，确认 Cleanup 能结束而不是永久阻塞。
• 检查失败日志，区分业务错误、超时取消和资源关闭错误。

相关问题

t.Context() 能替代所有测试里的 context 吗？

不能。它适合表达测试生命周期；业务操作仍可从它派生自己的超时或值语义上下文。不要把测试专属状态塞进生产函数依赖的全局变量。

为什么 Cleanup 里还要等待 done？

取消只发出停止信号，不保证 goroutine 已经返回。等待 done 才能把资源关闭和 goroutine 退出纳入测试结果。

最小验收是什么？

正常路径能完成任务，超时路径能触发 ctx.Done，Cleanup 不永久等待，并且日志能区分取消与业务失败。

最后的检查清单

把 t.Context() 传给真正拥有后台生命周期的函数；让 worker 监听 ctx.Done；用 t.Cleanup 等待退出并释放资源；最后用最低支持版本和一次故意超时的测试验证。这样改动的价值不在于少写一个 cancel，而在于测试结束时，每个 goroutine 都有明确的退出路径。