Go testing.T.Context 怎样让测试跟随取消

测试里启动了一个后台 goroutine，主测试函数返回后它还在打印日志、等待 channel，甚至继续访问已经准备清理的资源，这类问题通常不是“少写了一个 close”这么简单，而是测试生命周期没有传递给后台任务。Go 1.24 新增的 testing.T.Context 提供了一个直接的连接：测试完成后、注册的 Cleanup 函数运行前，这个上下文会被取消，后台工作可以从 Done() 收到退出信号。

官方文档：https://pkg.go.dev/testing#T.Context

版本说明：https://go.dev/doc/go1.24

本文只处理一个边界：测试结束时如何通知并等待子协程退出。t.Context() 负责发出取消信号，t.Cleanup() 负责在测试返回前等待收尾，二者配合起来才是完整的生命周期管理。

先复盘：测试通过了，后台任务却没结束

现场通常是这样的：测试函数创建一个 worker，worker 通过 ticker 或 channel 持续工作；断言完成后测试函数直接返回。此时 go test 可能已经显示通过，但 worker 仍然阻塞在下一轮等待中。短期看只是日志晚到，长期则可能表现为 goroutine 泄漏、端口或临时目录被过早清理，以及测试之间共享状态。

时间线可以拆成三段：测试主体完成断言；testing 包结束该测试并取消 t.Context()；Cleanup 回调开始执行。如果没有把这个 context 传给 worker，第二段发生时 worker 没有任何理由停止；如果没有在 Cleanup 中等待 worker，第三段结束时测试也可能先于资源收尾。

触发条件：只把 t 传进断言函数

很多测试辅助函数只接收 *testing.T，然后在内部启动 goroutine。问题在于，*testing.T 是测试控制对象，不是后台任务可以自行推断退出条件的业务 context。若 worker 没有接收 context.Context，它只能依赖一个额外的关闭 channel，或者一直运行到进程结束。

func startWorker(t *testing.T) 

这段写法的关键缺陷不是 goroutine 本身，而是它没有一个与测试生命周期绑定的停止信号。修复时先让工作函数显式接收 context，再由测试把 t.Context() 传进去。

根因定位：t.Context 的取消时机

t.Context() 返回的 context 会在测试完成后取消，并且发生在 Cleanup 函数调用之前。它不是一个“调用方法就立即取消”的手动 context，也不是把 -timeout 的截止时间直接复制过来的替代品。它表达的是测试生命周期结束这一件事。

这意味着 worker 应该把 ctx.Done() 放进自己的等待分支。如果测试因为断言失败、调用 FailNow 或正常走到函数末尾而结束，后台工作都能通过相同的取消入口收到信号。真正的清理动作仍应由 worker 自己完成，例如停止 ticker、关闭订阅或释放连接。

修复动作：让 worker 监听 Done 并释放资源

下面用一个可停止的轮询 worker 表示实际场景。它在每次工作间隔中同时等待 ticker 和 context；收到取消后先停止 ticker，再关闭结果通道并返回。这个顺序让资源释放集中在 worker 所属的 goroutine 内。

func runWorker(ctx context.Context, results chan

注意 context.Context 只负责通知，不会替 worker 自动执行 Stop、Close 或取消外部请求。每个阻塞点都要能观察 Done()；如果下游 API 本身支持 context，就继续把同一个 context 传下去。

用 Cleanup 等待 worker 真正退出

只把 t.Context() 传给 worker 还不够。测试结束时 context 会先取消，但 goroutine 可能还需要几步来关闭资源。可以用一个 sync.WaitGroup 登记 worker，再在 Cleanup 中等待它退出。由于 Context 的取消发生在 Cleanup 之前，Cleanup 能够稳定地等到 worker 看到取消并完成收尾。

func TestWorkerStopsWithTest(t *testing.T) {
	results := make(chan string, 4)
	var wg sync.WaitGroup
	wg.Add(1)

	go func() {
		defer wg.Done() // 保证 Cleanup 等待到 goroutine 的结束
		runWorker(t.Context(), results)
	}()

	t.Cleanup(func() {
		wg.Wait() // t.Context 已取消，worker 应从 Done 分支返回
	})

	// 这里放断言或触发一次测试事件；函数返回后生命周期会进入取消阶段。
}

这个模式的重点是两个方向都闭合：主测试把 context 传入，worker 在取消分支退出；Cleanup 再等待 worker 的退出。不要在 Cleanup 中另起一个永不结束的等待，也不要在 worker 里忽略 context 后指望 WaitGroup 自己产生取消。

几个容易混淆的边界

Context 不是超时断言。如果要判断一次操作是否超过测试超时，应结合 t.Deadline() 或使用 context.WithTimeout。t.Context() 只表达测试生命周期结束，并不把所有业务操作的截止时间自动传播成更短的 deadline。

并行测试要隔离资源。t.Parallel() 会改变测试调度关系。每个测试都应使用自己的 worker、channel 和资源，不能因为都能取得 context 就共享一个会被某个测试 Cleanup 关闭的对象。

Cleanup 的等待必须可完成。如果 worker 在取消分支仍会等待一个永远不会发送的 channel，wg.Wait() 会把问题暴露为测试卡住。应让所有阻塞等待都同时监听 context，必要时设置明确的辅助超时并保留原因。

防复发：把生命周期检查写进测试模板

以后在测试里启动后台任务，可以按四项检查收尾：第一，工作函数是否显式接收 context；第二，每个 ticker、channel、网络调用或队列等待是否能响应 Done()；第三，资源是否由 worker 在退出路径释放；第四，Cleanup 是否等待所有 goroutine 结束。四项中缺一项，测试都可能出现“主断言通过但后台还活着”的假成功。

如果被测代码暂时只能接收一个关闭 channel，可以在测试适配层用 context.AfterFunc 或一个小的转发 goroutine 把 context 取消映射到该 channel，但这只是过渡。优先让业务接口直接接受标准 context.Context，这样测试、HTTP 请求和命令行任务都能复用同一种取消语义。

最终可以把这次故障概括为：t.Context() 负责把“测试结束”变成可观察的取消事件，worker 负责响应事件并释放资源，Cleanup 负责确认退出已经完成。三者缺一不可。

相关问题

testing.T.Context 是从哪个 Go 版本开始的？

官方文档和 Go 1.24 发布说明都将 T.Context 标记为 Go 1.24 新增能力。低版本项目需要先确认工具链版本，不能直接调用这个方法。

测试函数返回后，worker 一定会被自动等待吗？

不会。Context 只提供取消信号，是否等待、如何释放资源仍由测试代码负责。用 Cleanup 配合 WaitGroup 或等价的完成信号，才能把退出纳入测试生命周期。

可以把 t.Context 当成每个操作的超时 context 吗？

不建议。它表示测试结束时的取消事件；需要操作级超时时，应根据业务调用创建带 deadline 的子 context，并仍然保留测试 context 作为上层取消来源。