Go testing.TB.Context 如何绑定测试取消：清理时机与子协程退出检查

测试用例明明已经返回，CI 却偶尔在下一轮报出后台 goroutine 仍未退出。最容易被忽略的边界是：测试上下文的取消发生在什么时候，Cleanup 又应该验收什么。Go 的 testing.TB.Context() 可以把测试生命周期传给子协程，但它不是“在 Cleanup 里等待自己结束”的万能开关。

先复现：测试结束了，后台工作还在跑

下面这个小例子故意让 worker 忽略取消。它能帮助你区分“Context 已经取消”和“goroutine 已经退出”这两件事：

func startWorker(ctx context.Context, done chan

如果 worker 正确监听 ctx.Done()，测试结束时它会收到取消信号。但仅凭 Context 的状态，不能证明它已经执行完 defer、释放资源并退出调度。

取消链路：TB.Context 何时变成 Done

testing.TB 提供的 Context() 返回一个与当前测试绑定的上下文。测试完成，或者注册的 Cleanup 函数返回后，这个上下文会被取消。它适合传给需要随测试一起停止的服务器、轮询器和消费者。

这里有个很关键的顺序：如果你在 Cleanup 中等待 ，等待本身可能永远不会开始结束，因为该 Context 要等 Cleanup 返回后才取消。停止后台工作应使用自己的 cancel 函数，TB Context 只负责把测试生命周期传入工作逻辑。

修复动作：停止信号与退出信号分成两条线

一个更稳的结构是创建独立的 context.WithCancel，同时保留 tb.Context() 作为上游取消来源。worker 退出时关闭 done channel，Cleanup 负责调用 cancel 并等待 done：

func runWorker(tb testing.TB) {
    tb.Helper()
    ctx, cancel := context.WithCancel(tb.Context())
    done := make(chan struct{})

    go startWorker(ctx, done)
    tb.Cleanup(func() {
        cancel()
        select {
        case 

可见的成功状态不是“Cleanup 被调用”，而是 done channel 在超时前收到关闭事件。这样测试才真正验收了后台协程退出，而不只是发出停止请求。

Cleanup 顺序：先释放依赖，再验收最后一个 worker

多个 Cleanup 按注册顺序的逆序执行。若 worker 依赖一个测试服务器，建议先注册服务器清理，再注册 worker 清理，让 worker 的清理函数后注册、先执行，避免它在等待退出时继续访问已经关闭的依赖。

如果工作协程还会写结果 channel，退出前必须停止生产者，再由测试读取或关闭消费者侧资源。不要在 Cleanup 里直接关闭一个可能仍被 worker 写入的 channel；这类竞态通常只在并发 CI 上出现。

最后验收：三个信号分别代表什么

• ctx.Done：后台逻辑收到停止请求，说明取消链路接通。
• done：goroutine 已执行退出路径，说明资源清理可以继续。
• 超时：实现没有在约定窗口内停下，测试应该失败并暴露问题。

常见问题

可以只等待 testing.TB.Context 的 Done 吗？

不建议。它表达的是测试生命周期取消，不是某个 goroutine 已经完成退出。Cleanup 中应等待自己的 done 信号。

为什么测试返回后 Context 还没立刻取消？

取消时机由 testing 管理，并且与测试完成和 Cleanup 返回相关。不要把它当成普通请求上下文的手动 cancel 替代品。

退出等待应该设置多长超时？

按 worker 的正常收尾耗时设置一个明确上限，例如一秒或更短的测试预算。关键是超时要让测试失败，而不是静默泄漏。

小结

testing.TB.Context() 解决的是“测试生命周期如何传入后台工作”；独立 cancel 和 done 信号解决的是“如何停止并证明它真的退出”。把这两件事分开，Cleanup 才能从发信号升级为可验证的资源回收。