Go testing.T Cleanup 失败时为什么测试仍继续

很多 Go 测试日志会出现一种看似矛盾的情况：t.Cleanup 里已经报错，后面的测试输出却还在出现。关键不在于 Cleanup 失败被忽略，而在于它本来就不是注册点上的同步调用。Cleanup 会等当前测试及其子测试结束后才运行；清理回调中的失败通常先把测试标记为失败，再由测试框架完成剩余收尾。

Cleanup 注册时不会立刻执行

调用 t.Cleanup(func() { ... }) 做的是登记回调，不是执行回调。官方 testing 包规定，当前测试或子测试全部完成后才调用它，并且按最后注册、最先执行的顺序处理。因此下面的日志顺序是正常的：先打印测试体日志，再打印 Cleanup 日志，最后汇总测试失败。

func TestCache(t *testing.T) {
    // 注册资源释放动作；这里不会立刻关闭连接。
    t.Cleanup(func() {
        // 清理动作发生在测试函数主体返回之后。
        t.Log("cleanup: close cache")
    })

    // 测试主体仍会从这里继续执行。
    t.Log("test body: query cache")
}

失败标记不等于立即终止

t.Error 等价于记录日志再调用 Fail，它会把测试标记为失败，但允许当前函数继续。t.Fatal 则通过 FailNow 结束当前测试 goroutine。两者放在 Cleanup 里也不能改变“Cleanup 已经处于收尾阶段”的事实：t.Fatal 会结束当前清理回调，测试框架仍会执行其他已登记的清理；panic 也会被框架捕获并继续处理剩余回调。

用返回路径处理清理错误

资源关闭失败通常应该让测试失败，但不必让错误处理本身制造新的 panic。先保留资源名称和阶段，再记录原始错误；如果当前清理回调后面的逻辑已经没有意义，就直接 return。这样既能让测试结果变成失败，也不会阻止框架执行其他资源的 Cleanup。

func TestStore(t *testing.T) {
    store := openStore()
    t.Cleanup(func() {
        // 关闭失败要保留资源名，便于从并行测试日志中定位。
        if err := store.Close(); err != nil {
            t.Errorf("cleanup store: %v", err)
            // 当前清理函数到此为止，其他 Cleanup 仍由框架调度。
            return
        }
        t.Log("cleanup store: closed")
    })

    // 前置条件失败要在测试体内立即终止，而不是等 Cleanup 才发现。
    if err := store.Ping(); err != nil {
        t.Fatalf("store is unavailable: %v", err)
    }
}

排查测试仍继续的检查清单

先看错误日志来自测试体还是 Cleanup：如果调用栈指向资源释放函数，说明主体很可能已经执行完。再检查是否存在子测试；父测试的 Cleanup 要等子测试结束，不能用它阻止子测试内部已经发生的操作。最后按注册顺序反推执行顺序，尤其注意循环里注册的多个回调。

如果目标是阻止后续断言，应该把检查放回测试体并使用 t.Fatal；如果目标是无论测试成功还是失败都释放资源，就保留 t.Cleanup，让它只负责释放和上报。不要用“Cleanup 报错后日志还在继续”判断框架失效，这正是测试生命周期设计的一部分。

常见问题

t.Cleanup 为什么不是注册后立即执行？

它是测试生命周期的收尾回调，设计目标是无论测试体成功、失败还是调用 FailNow，都能统一释放资源。

Cleanup 里用 t.Error 后为什么还能看到后续日志？

因为 t.Error 只设置失败状态，不结束当前函数；如果日志来自其他 Cleanup，则还会按逆序继续执行。

想让 Cleanup 失败就停止所有清理怎么办？

通常不应停止所有清理；每个资源都要有机会释放。应在当前回调内记录错误并返回，必要时把关键前置检查移到测试体，用 t.Fatal 立即终止。