testing.T.Context 取消后并发断言的收尾方式

testing.T.Context() 最适合用来管理测试启动的后台 goroutine：把它传给工作函数，测试函数返回后，testing 会先取消这个 Context，再运行 Cleanup。因此可以在 Cleanup 中等待 goroutine 退出、收集错误并完成断言。

稳定的收尾方式是把三件事分开：ctx.Done() 负责发出停止信号，done 负责证明 goroutine 已退出，errCh 负责把结果交回测试 goroutine。后台 goroutine 不调用 t.Fatal。

先确认 Context 和 Cleanup 的接口时序

Go 1.24 为 *testing.T 增加了 Context 方法。官方契约很明确：返回的 Context 会在 Cleanup 注册函数被调用之前取消。Cleanup 则在当前测试或子测试以及它的全部子测试完成后运行，并按后注册先调用的顺序执行。

这让测试框架成为生命周期的所有者。测试代码不必额外猜测何时调用 cancel()，资源也不需要依赖任意的 sleep。需要明确区分的是：

• Context 取消只表示“应该停止”，不表示 goroutine 已经退出。
• Cleanup 可以等待退出，但需要一个可观察的完成信号。
• 断言应消费最终结果，而不是与后台工作同时读取共享变量。

把停止信号、完成通知和结果通道拆开

下面的最小示例启动一个循环工作函数。工作函数只接收 context.Context，并在取消后返回；测试再用两个缓冲/关闭信号承接退出状态和错误。

package collector

import (
    "context"
    "errors"
    "testing"
    "time"
)

func runCollector(ctx context.Context) error {
    ticker := time.NewTicker(10 * time.Millisecond)
    defer ticker.Stop() // 中文注释：退出时释放计时器资源

    for {
        select {
        case 

这里的 done 不能被 ctx.Done() 替代。前者证明工作 goroutine 已完成所有 defer 和返回动作，后者只证明取消信号已经发出。errCh 设为容量 1，也让工作函数即使早于 Cleanup 返回，仍能交付结果而不阻塞。

在 Cleanup 中集中完成并发断言

接口设计的关键是把“产生事实”和“判定测试失败”分开。worker 只产生错误值，Cleanup 负责等待、读取并调用 t.Errorf。这样做有三个好处：

1. 断言前已经确认后台资源退出，不会一边修改状态一边检查结果。
2. 失败报告集中在测试所有者的收尾位置，日志不容易晚于测试生命周期。
3. 取消本身可以被视为预期结果，真正异常才标记测试失败。

如果有多个 worker，可以用 sync.WaitGroup 聚合完成状态，并让错误通道容量至少覆盖 worker 数量。不要在 Cleanup 等待时才使用无缓冲通道接收第一条错误，因为其他 worker 可能在发送阶段互相阻塞。

func runWorker(ctx context.Context, id int) error {
    // 中文注释：真实项目可在这里执行带编号的后台任务
    return runCollector(ctx)
}

func TestWorkersStop(t *testing.T) {
    ctx := t.Context()
    const workers = 3

    errCh := make(chan error, workers) // 中文注释：每个 worker 最多发送一次
    var wg sync.WaitGroup
    wg.Add(workers)

    for id := range workers {
        go func() {
            defer wg.Done()
            errCh 

示例中的 for id := range workers 需要支持整数 range 的 Go 版本；若项目仍使用更早语言版本，可改成传统的 for id := 0; id 。这不影响 Context 与 Cleanup 的收尾模型。

后台 goroutine 不要调用 t.Fatal

t.Fatal 等价于记录日志后调用 FailNow。官方文档要求 FailNow、Fatal 和 Fatalf 只能由运行测试函数的 goroutine 调用。它们内部使用 runtime.Goexit，从后台 goroutine 调用只会终止当前后台 goroutine，并不会替测试框架停止其他 goroutine。

t.Error 和 t.Log 等报告方法允许多个 goroutine 并发调用，但“允许”不等于“适合所有收尾”。如果 worker 可能在测试函数返回后才报告，就容易出现晚到日志或资源仍在运行的问题。将错误值发送回来，再由 Cleanup 统一报告，通常更容易推理。

兼容 Go 1.23 及更早版本时要处理 LIFO 顺序

没有 T.Context 时，可以自己创建可取消 Context，但要注意 Cleanup 后注册先执行。若等待 Cleanup 先于 cancel 执行，测试会死锁。正确注册顺序是先注册“等待并断言”，再注册 cancel，这样运行时会先 cancel、后 wait。

func TestLegacyCleanupOrder(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    done := make(chan struct{})

    go func() {
        defer close(done)
        

T.Context 的价值之一，就是把这条容易写反的顺序交给 testing 包。升级到 Go 1.24 以上后，不需要为了测试结束专门维护 cancel，但业务内部若还派生了独立超时 Context，仍应按它自己的责任调用对应 cancel 函数。

并发测试收尾检查清单

• 所有后台函数是否都接收并监听 t.Context() 或其派生 Context？
• Context 取消之外，是否还有 done 或 WaitGroup 证明 goroutine 真正退出？
• 结果通道是否有足够容量，避免 Cleanup 尚未接收时 worker 被发送操作卡住？
• 错误是否回到 Cleanup 集中判断，而不是在 worker 中调用 t.Fatal？
• Cleanup 是否可能无限等待？若被测代码可能忽略 Context，应增加独立的超时保护并输出明确错误。
• 子测试是否使用自己的 t.Context()，让生命周期绑定到对应子测试？

最重要的不是把所有断言都塞进 Cleanup，而是让资源退出和失败判定拥有清晰归属。T.Context 负责测试生命周期的取消契约，channel 或 WaitGroup 负责可观察完成，Cleanup 负责最后一次同步和报告。三者分开后，并发测试通常会比“goroutine 里直接 Fatal”更稳定。

常见问题

T.Context 会在测试超时时自动带上 Deadline 吗？

官方文档只保证该 Context 在 Cleanup 前取消，不应把它当成 T.Deadline() 的替代。如果业务逻辑必须感知特定截止时间，应基于测试需求显式派生带超时的 Context。

Cleanup 中可以调用 t.Errorf 吗？

可以把 Cleanup 作为收尾断言位置。建议先等待 worker 完成，再读取稳定结果并报告错误，避免断言与资源修改并行发生。

只等待 ctx.Done 为什么不够？

ctx.Done() 关闭代表取消已发出，不代表 worker 已执行完 defer、关闭连接或写入最终结果。还需要独立完成信号。

多个 Cleanup 的执行顺序是什么？

按后注册先调用，也就是 LIFO。手动 cancel 与 wait 分拆时必须据此安排注册顺序。

参考资料

• Go testing 官方文档：T.Context
• Go testing 官方文档：T.Cleanup
• Go testing 官方文档：T.FailNow
• Go 1.24 发布说明：testing 更新