Go testing/synctest 实战：别再用 time.Sleep 赌并发测试会过

Go 项目里最让人头疼的一类测试，不是不会写断言，而是测试本身不稳定：本地能过，CI 偶尔红；你把 time.Sleep(10 * time.Millisecond) 改成 100ms，好像稳了一点，但测试套件也越来越慢。Go 1.25 正式加入的 testing/synctest，就是冲着这类并发和时间相关测试来的。

我最近看 Go 1.25 release notes 和 Go 官方博客时，最想拿出来单独聊的就是它。因为它解决的不是炫技问题，而是很多后端团队每天都会遇到的老毛病：定时器、超时、goroutine、channel、重试退避这些代码，到底怎么测得又快又稳。

为什么 time.Sleep 测并发很容易翻车

很多并发测试一开始都是这么写的：启动一个 goroutine，等几十毫秒，然后检查结果。问题是这几十毫秒没有任何语义，它只是一个赌注：赌机器够快，赌 CI 没抖，赌调度器刚好给你的 goroutine 时间片。

这种测试最麻烦的地方，是它失败时你很难判断到底是业务代码错了，还是测试写得脆。于是大家会继续把 sleep 调大，从 10ms 到 100ms，再到 1s。测试好像稳了，反馈速度也被一点点拖慢。

synctest 到底带来了什么

Go 1.25 的 testing/synctest 提供了一个测试气泡。你把测试逻辑放进 synctest.Test 里，气泡内的时间会被虚拟化；当气泡里的 goroutine 都阻塞时，虚拟时间可以瞬间向前推进。配合 synctest.Wait，测试可以等到后台 goroutine 进入稳定阻塞状态。

这句话听起来有点抽象，翻译成工程语言就是：你不用再真的等 5 秒过期、30 秒超时、1 分钟重试。测试可以在很短时间内模拟这些时间流逝，而且比靠 sleep 更可控。

一个典型例子：测试缓存过期

假设你有一个本地缓存，写入后 5 秒过期。过去我见过不少测试会真的 sleep 5 秒多一点，这种测试单独看没什么，一旦有几十个类似用例，CI 时间就很难看。

func TestCacheExpires(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        c := NewCache(5 * time.Second)
        c.Set("uid:1", "cola")

        if got, ok := c.Get("uid:1"); !ok || got != "cola" {
            t.Fatalf("cache miss before ttl")
        }

        time.Sleep(5*time.Second + time.Nanosecond)
        synctest.Wait()

        if _, ok := c.Get("uid:1"); ok {
            t.Fatalf("cache should expire")
        }
    })
}

这里的重点不是 API 多漂亮，而是测试语义变清楚了：我不是“等一会儿看看”，而是明确推进到 TTL 之后，再等气泡内相关 goroutine 稳定下来，然后断言状态。

第二个场景：测试后台 goroutine

很多线上 bug 都藏在后台 goroutine 里。比如你启动一个 worker，收到任务后写结果，空闲时等定时器 flush。传统测试经常要睡一下再检查；synctest 更适合把这个等待变成可解释的同步点。

func TestWorkerFlush(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        w := NewWorker(10 * time.Second)
        w.Add("a")

        synctest.Wait()
        if w.FlushCount() != 0 {
            t.Fatalf("flush too early")
        }

        time.Sleep(10 * time.Second)
        synctest.Wait()

        if w.FlushCount() != 1 {
            t.Fatalf("flush count = %d, want 1", w.FlushCount())
        }
    })
}

synctest.Wait 不是万能暂停键，它的意义是等气泡里的 goroutine 都阻塞。这个点很关键：你要先让代码进入可等待的状态，再判断结果，而不是靠运气猜 goroutine 已经跑完。

我会怎么在老项目里落地

第一步不是全项目替换，而是先搜 time.Sleep。如果它出现在测试文件里，而且注释写着“wait goroutine done”“wait cache expire”“wait timeout”，这类用例就很适合先改。

第二步是从慢测试下手。比如某个测试为了等重试退避，跑一次要几秒；这类改成虚拟时间后，收益最明显，团队也更容易接受。

第三步是保留一小部分真实集成测试。synctest 很适合单元测试和组件级测试，但涉及真实网络、真实数据库、真实消息队列时，还是要有端到端测试兜底。别把一个好工具用成另一个银弹。

容易误用的地方

第一个误区是把它当成“让所有并发 bug 消失”的工具。它能让时间和等待更可控，但如果你的代码本身有数据竞争，还是要靠 race detector、清晰的同步设计和代码 review。

第二个误区是测试写得太贴实现。比如你断言某个 goroutine 必须在某个内部步骤阻塞，这会让测试和实现强绑定。我的习惯是断言外部行为：是否超时、是否过期、是否 flush、是否取消。

第三个误区是不理解版本差异。它在 Go 1.24 还是实验能力，到 Go 1.25 才以新的 API 正式进入标准库。老项目升级时，先确认 CI 使用的 Go 版本，别让本地和流水线跑两套行为。

我的 review 清单

• 测试里有没有无语义的 time.Sleep？它是在等时间，还是在等 goroutine？
• 如果是在等时间，能不能放进 synctest.Test 里用虚拟时间推进？
• 如果是在等 goroutine，能不能用 synctest.Wait 或明确的 channel/WaitGroup 表达同步？
• 断言的是外部行为，还是某个脆弱的内部调度细节？
• 这个测试在 go test -race 下是否仍然稳定？
• CI 的 Go 版本是否已经到 1.25，并且团队知道 Go 1.24 实验 API 的差异？

最后聊两句

我挺喜欢 testing/synctest 的原因，是它没有鼓励我们写更复杂的测试框架，而是把并发测试里最烦人的“等一下”变成了更明确的测试语义。测试本来就应该告诉读代码的人：我在等什么，为什么现在可以断言。

如果你的项目里有一堆偶发红的并发测试，先别急着继续加 sleep。挑一两个最慢、最脆的用例，用 synctest 改掉。你会很快感受到那种舒服：测试更快了，也更像是在验证逻辑，而不是在和调度器掷骰子。