Go testing.T.Cleanup 怎么验证子测试清理顺序：注册时机、并发子测试与失败定位

测试用例一多，临时目录、数据库连接和环境变量很容易在失败路径上留下痕迹。Go 的 testing.T.Cleanup 适合把这些收尾动作绑定到测试生命周期，但它不是“当前函数返回就执行”的普通 defer：注册在哪个 *testing.T 上，决定了清理要等到哪个测试节点完成。

先用一组日志看清 Cleanup 的执行顺序

最小实验不需要真实数据库。用一个字符串切片记录事件，再注册两个清理函数，就能直接看到顺序。下面的测试故意让第二个清理函数先执行：

func TestCleanupOrder(t *testing.T) {
    var events []string
    t.Cleanup(func() { events = append(events, "cleanup-A") })
    t.Cleanup(func() { events = append(events, "cleanup-B") })

    events = append(events, "body")
    t.Logf("body events: %v", events)
}

两个函数都绑定在同一个测试节点上，执行结果是 body、cleanup-B、cleanup-A。这和栈式的资源撤销很接近：后创建的资源先释放，能减少依赖关系倒置。

注册在父测试还是子测试，等待点并不一样

t.Cleanup 注册的是“当前测试及其所有子测试完成后的动作”。因此父测试上的清理函数不会在某个 t.Run 返回的瞬间就执行，而是等父测试管理的子测试全部结束。

func TestFixture(t *testing.T) {
    fixture := newFixture()
    t.Cleanup(func() { fixture.Close() })

    t.Run("valid", func(t *testing.T) {
        useFixture(t, fixture)
    })
    t.Run("invalid", func(t *testing.T) {
        useFixture(t, fixture)
    })
}

这种写法把夹具的生命周期放在父节点，两个子测试共享它但不会提前关闭。若把 fixture.Close() 写成父函数里的普通 defer，它通常也能覆盖这段顺序代码；但一旦清理逻辑需要和测试节点、失败状态或并行子测试绑定，Cleanup 的语义更明确，也更容易复用到辅助函数中。

失败测试不会跳过清理，日志要记录在 Cleanup 里面

清理函数会在测试失败、调用 t.Fatal 或子测试被跳过后运行。不要只在测试主体里打印“准备释放”，否则最关键的失败路径反而看不到实际收尾。

func tempEnv(t *testing.T, key, value string) {
    old, existed := os.LookupEnv(key)
    if err := os.Setenv(key, value); err != nil {
        t.Fatal(err)
    }
    t.Cleanup(func() {
        if existed {
            _ = os.Setenv(key, old)
        } else {
            _ = os.Unsetenv(key)
        }
        t.Logf("restored %s", key)
    })
}

辅助函数接收 *testing.T 并在内部注册 Cleanup，是标准的测试夹具写法。调用者不需要记住恢复动作，也不会因为中途失败而遗漏环境变量。

t.Parallel 下怎样避免共享资源过早释放

并行子测试会在调用 t.Parallel() 后暂停，直到父测试函数返回；父级 t.Run 也会等待这些并行子测试完成。因此共享资源可以由父测试创建，并由父测试的 Cleanup 统一释放。

func TestParallelUsers(t *testing.T) {
    fixture := newFixture()
    t.Cleanup(func() { fixture.Close() })

    for _, name := range []string{"alice", "bob"} {
        name := name
        t.Run(name, func(t *testing.T) {
            t.Parallel()
            if err := fixture.Check(name); err != nil {
                t.Fatal(err)
            }
        })
    }
}

这里还有一个独立的 Go 循环变量问题：示例显式保存 name，让每个子测试使用自己的值。资源本身也必须支持并发访问；Cleanup 只保证释放时机，不会替你加锁。

用可重复检查把顺序问题固定下来

验证清理顺序时，建议把事件写到一个带互斥保护的记录器，再在父测试完成后检查结果。不要依赖测试输出的偶然排列，也不要在并行清理函数里直接读写普通切片。

type events struct {
    sync.Mutex
    items []string
}

func (e *events) add(item string) {
    e.Lock()
    defer e.Unlock()
    e.items = append(e.items, item)
}

普通同层 Cleanup 的顺序可以精确断言；并行子测试之间的完成先后则不应写成固定断言，应该只检查“所有子测试完成后共享资源才关闭”这一不变量。运行时配合 go test -run TestParallelUsers -count=30，更容易暴露偶发的提前关闭。

常见问题

Cleanup 和 defer 应该怎么选？

只服务于当前函数局部变量的同步收尾，defer 足够；需要绑定测试节点、覆盖 Fatal/Skip 或由辅助夹具统一注册时，优先使用 Cleanup。

Cleanup 函数里发生错误怎么办？

不要静默吞掉关键错误。可以用 t.Errorf 记录失败，但要注意清理阶段不适合再调用会终止测试的 Fatal 系列方法。

并行子测试能否自己关闭父级共享资源？

不应该。并行子测试只释放自己创建的资源，父级创建的夹具交给父级 Cleanup，避免一个子测试结束后影响其他并行用例。

把生命周期写在注册点，测试才容易维护

Cleanup 的价值不只是少写几行恢复代码，而是把资源归属写在测试树上：子测试自己的资源由子测试清理，父级共享夹具由父级清理，同一节点上的多个动作按逆序撤销。先用日志验证顺序，再用失败和并发场景跑几轮，通常就能发现那些只在 CI 偶尔出现的资源泄漏和提前关闭。