Go testing.T.Context 怎么用：测试取消、子协程收尾与时序核对

测试里启动了一个监听配置刷新或后台轮询的 goroutine，函数本身已经返回，进程却迟迟不干净。Go 1.24 提供的 testing.T.Context() 正好解决这类收尾问题：测试函数完成后、注册的 Cleanup 执行前，上下文会被取消，子协程可以据此退出。

先看一个测试结束不了的现场

下面这个例子模拟后台协程每隔一小段时间处理一次任务。旧写法如果只靠一个永不关闭的 channel，测试函数虽然通过，后台工作却还活着；如果测试包里还有共享资源，后面的用例就可能被它影响。

func watch(ctx context.Context, done chan

这段函数的关键不在定时器，而在 ctx.Done()。没有这一支，测试框架没有办法告诉它“测试已经结束，可以收尾了”。

最小写法：把 t.Context 传到真正的工作边界

测试函数里直接取出上下文，再把它传给被测函数或后台组件。不要在业务函数内部重新创建一个脱离测试生命周期的 context.Background()，否则取消信号到不了真正的工作边界。

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

    go watch(ctx, done)

    t.Cleanup(func() {
        select {
        case 

这里的核对点有两个：watch 必须监听同一个 ctx，而 Cleanup 必须等待 done。只写前一半，无法证明协程确实退出；只写后一半，则可能一直等到超时。

取消顺序和 Cleanup 顺序不要混在一起

t.Context() 返回的上下文会在测试完成、Cleanup 回调运行前取消。这个顺序很适合“先通知后台工作停止，再在 Cleanup 里等待它释放资源”的场景：

1. 测试函数返回，测试框架取消 t.Context()。
2. 后台协程从 ctx.Done() 收到信号，关闭资源并发送 done。
3. t.Cleanup 被调用，等待并核对后台协程已经完成。

不要在测试函数最后手动调用一个业务层的全局取消函数，再把 t.Context() 当成第二套控制信号。测试越多，两个取消源越容易出现一边退出、一边继续写共享状态的竞态。

超时、失败和主动取消分别怎么判断

t.Context() 的取消时机是测试生命周期语义，不等于 go test -timeout 的超时诊断。需要知道测试是否真的因为框架超时而结束时，仍然要查看测试输出和 t.Deadline()。

如果组件本身还需要业务取消、请求截止时间或父级租户上下文，可以使用 context.WithCancel 派生子上下文，再把测试上下文作为父级。测试结束时父级取消，业务层自己的取消仍然可以在单测中单独验证。

用 race 和重复运行确认没有漏网协程

先跑一次带竞态检测的测试：

go test -race -count=1 ./...

然后把测试重复运行几次，观察是否出现偶发的 watcher did not stop、发送到已关闭 channel 或共享状态被并发修改。t.Context() 只能提供取消信号，不能替你修复 channel 所有权、锁粒度或资源释放顺序。

常见问题

testing.T.Context 从哪个 Go 版本开始可用？

它从 Go 1.24 开始加入 testing.T。项目如果需要兼容更早版本，应先确认 go.mod 和构建矩阵，不能只在本机新版本通过后直接提交。

Cleanup 里还能读取 t.Context 吗？

可以读取，但此时上下文已经处于取消状态。Cleanup 更适合等待资源关闭、核对完成信号和清理临时数据，不适合再启动依赖该上下文的长任务。

传入 t.Context 后 goroutine 会自动退出吗？

不会。被测代码必须主动选择 ctx.Done()，并确保所有阻塞点都能回到这条退出路径。

小结

把 t.Context() 当作测试生命周期的父信号，把 done 当作协程完成证据，再在 Cleanup 中等待和核对，收尾逻辑就清楚了。真正需要回归的不是“有没有传 Context”，而是取消后每个工作分支是否都能退出、资源是否只由一个边界负责释放。