Go testing.T.FailNow 为什么不能从子 goroutine 调用

在并发测试里，最容易误用的一件事，是让子 goroutine 直接调用 t.FailNow() 或 t.Fatal()。这段代码看起来像“发现错误就立刻结束测试”，实际上结束的只是调用它的 goroutine；外层测试函数可能继续向下执行，甚至在没有继续检查结果时误报通过。

官方文档：https://pkg.go.dev/testing#T.FailNow

把 FailNow、Fatal 和 SkipNow 留在运行测试函数的 goroutine 中。子 goroutine 只负责完成工作、返回错误或发送结果；主测试 goroutine 收到结果后，再决定是否失败。

FailNow 真正停止的是什么

FailNow 会先把当前测试标记为失败，然后通过 runtime.Goexit 停止当前 goroutine 的继续执行。当前 goroutine 中已经注册的 defer 仍会执行，测试框架随后继续处理下一个测试或基准任务。

这和普通的 Fail 不同：Fail 只记录失败，不会立即离开当前函数；Fatal 则相当于先记录日志，再调用 FailNow。三者的区别可以先记成下面这张小表：

为什么从子 goroutine 调用会留下隐患

Go 官方对 testing.TB.FailNow 的说明明确要求：它必须从运行测试或基准函数的 goroutine 调用，不能从测试期间创建的其他 goroutine 调用。原因不是“goroutine 不能访问 *testing.T”，而是 FailNow 的停止语义与当前执行栈绑定。

下面的写法把失败控制交给了 worker。worker 调用 FailNow 后会结束自己，但 TestWrong 仍然可能继续执行；如果测试函数没有检查共享状态或等待另一个失败信号，测试结果就和作者想象的不一样。

func TestWrong(t *testing.T) {
    done := make(chan struct{})
    go func() {
        defer close(done) // 子 goroutine 退出时通知主测试
        t.FailNow()       // 错误：只结束这个子 goroutine
    }()

    

还要注意，FailNow 不会替你停止其他 goroutine。即使主测试 goroutine 正确失败，已经启动的 worker 仍需要自己的退出条件；否则它可能继续占用连接、等待 channel，或者让测试进程在其他地方卡住。

让 worker 返回错误，再由测试函数判定

更稳的分工是：worker 不调用 FailNow，只把错误送回主测试 goroutine。错误通道使用容量为 1 的缓冲，可以避免主测试因为提前返回而让单个 worker 永久阻塞在发送动作上。

func TestWorker(t *testing.T) {
    errCh := make(chan error, 1) // 只接收一次失败结果，避免发送方被卡住

    go func() {
        errCh 

如果有多个 worker，就为每个任务收集结果，并在主测试函数中等待所有任务结束或先取消剩余任务。不要为了“尽快失败”而把 Fatalf 塞进 worker；快速返回和安全收尾是两件事，后者需要显式的等待与取消策略。

defer、Cleanup 和 worker 退出要分开安排

FailNow 使用 runtime.Goexit 离开当前 goroutine，因此当前 goroutine 的 defer 仍有机会执行；但子 goroutine 自己的 defer 只会在子 goroutine 自己返回或退出时执行。主测试函数的 defer 不会因为某个 worker 退出而自动触发。

t.Cleanup 适合注册测试级清理动作，例如删除临时资源或关闭测试夹具，但它也不是 goroutine 回收器。把 worker 的生命周期和测试函数绑定起来，通常要组合这几件事：

• 主测试函数创建取消信号或上下文，让 worker 有明确的退出路径。
• worker 在退出前关闭自己持有的资源，并把错误送回结果通道。
• 主测试函数在返回前等待 worker，避免清理开始时仍有异步写入。
• 测试级资源使用 t.Cleanup 统一登记，但不要把它当作等待 worker 的替代品。

func TestWithCleanup(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    t.Cleanup(cancel) // 测试结束时取消仍未完成的工作

    errCh := make(chan error, 1)
    go func() {
        // worker 应监听 ctx.Done，并在退出前释放自己的资源。
        errCh 

示例中的关键点不是某一个 channel 写法，而是失败控制只有一个归属点：主测试 goroutine。worker 可以并发，但不能在测试框架的终止 API 上各自做决定。

遇到测试卡住或误通过时怎么查

1. 先搜所有 FailNow、Fatal 和 SkipNow，确认它们是否位于测试函数自身的 goroutine。
2. 检查 worker 是否有结果通道、取消信号和退出等待；只有 close(done) 不代表测试失败已经被主函数接收。
3. 确认错误通道是否可能阻塞发送，尤其是主测试提前返回、多个 worker 共用无缓冲 channel 的情况。
4. 把 t.Cleanup 中的资源清理与 worker 自身的退出逻辑分开，避免用清理回调掩盖 goroutine 泄漏。

最后可以用一句话做代码审查：谁创建了 goroutine，谁等待它结束；谁运行测试函数，谁调用 FailNow。遵守这个分工，异步测试的失败状态、清理顺序和退出边界就不会混在一起。

相关问题

Fail 和 FailNow 应该怎么选？

还需要继续执行并收集多个断言时用 Fail；当前条件已经让后续步骤失去意义时，在测试函数 goroutine 中用 FailNow 或 Fatal。

子 goroutine 发现错误能不能直接调用 t.Errorf？

错误记录与立即终止是两回事。并发测试更建议让 worker 返回错误，由主测试函数统一记录或终止；不要把测试生命周期控制散落在多个 goroutine。

为什么调用 FailNow 后 defer 还会执行？

因为 FailNow 通过 runtime.Goexit 结束当前 goroutine，Go 会先执行该 goroutine 已注册的 defer。它不会替其他 goroutine 执行清理，也不会自动等待其他任务。