Go testing/synctest 并发测试调用 Sleep 后仍不稳定怎么办

我第一次把并发测试改成 testing/synctest 时，最容易误判的一点就是：把 time.Sleep 换进 bubble 后，测试就一定稳定。实际并不是这样。Go 1.27 新增的 synctest.Sleep 解决的是“推进虚拟时间后，再等 bubble 内其它 goroutine 稳定下来”；如果仍然只调用 time.Sleep、测试没有进入 bubble，或者被测代码卡在真实 I/O 上，结果依旧可能抢跑。

先给结论：稳定写法是把测试放进 synctest.Test，用 synctest.Sleep(d) 等待被测任务在虚拟时间中完成，再读取结果。Sleep 等价于 time.Sleep(d) 加 synctest.Wait()；它不能替你等待 bubble 外的 goroutine，也不能把真实网络变成确定性的虚拟网络。

官方文档：https://pkg.go.dev/testing/synctest@go1.27.3#Sleep

Go 1.27 为什么要新增 synctest.Sleep

testing/synctest 在 Go 1.25 进入标准库。bubble 内的 time 使用虚拟时钟，只有当 bubble 中的 goroutine 都处于可判断的阻塞状态时，时间才会向前推进。Go 1.27 的 Sleep 把“等待一段虚拟时间”和“等待其它 goroutine 稳定阻塞”合在了一起。

这解决了一个很隐蔽的竞争：测试 goroutine 和被测 goroutine 都等待相同的 100*time.Millisecond 时，时间到了以后谁先继续并没有业务保证。测试可能先醒来读取旧值，也可能被测任务先完成，于是本地偶尔通过、CI 偶尔失败。

为什么只写 time.Sleep 仍可能抢跑

下面这个例子把“延迟后写入结果”的任务放入 bubble，但测试只调用 time.Sleep。时间确实会推进，可是测试醒来时，被测 goroutine 不一定已经完成最后一次调度。

package flaky

import (
    "testing"
    "testing/synctest"
    "time"
)

func TestWithTimeSleep(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        done := make(chan struct{})
        go func() {
            // 这是被测任务的虚拟延迟，不代表真实等待 20 毫秒。
            time.Sleep(20 * time.Millisecond)
            close(done)
        }()

        // 只推进时间；测试可能先于后台 goroutine 观察到最终状态。
        time.Sleep(20 * time.Millisecond)
        select {
        case 

图中的关键关系不是“睡眠多久”，而是时间域与同步域被拆开了。time.Sleep 只表达等待时长；synctest.Wait 才表达“让 bubble 内可推进的后台工作先汇合”。

把等长等待改成 synctest.Sleep

Go 1.27 及以上版本可以直接使用 synctest.Sleep。它在当前 bubble 中等待虚拟时钟前进，同时等待其它 bubble goroutine 进入 durable blocked 状态，因此测试读取结果时不再依赖“这次调度谁先醒”。

func TestWithSynctestSleep(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        done := make(chan struct{})
        go func() {
            // 被测 goroutine 与测试 goroutine 使用同一个虚拟时间域。
            time.Sleep(20 * time.Millisecond)
            close(done)
        }()

        // Sleep 同时推进虚拟时间并等待 bubble 内其它 goroutine 稳定。
        synctest.Sleep(20 * time.Millisecond)
        select {
        case 

如果任务是通过定时器、超时 context 或 time.After 触发，这个写法尤其直观：测试只描述“虚拟时间到达目标点”，而不是猜测真实机器需要多长时间。

仍然不稳定时先查这四个边界

如果改成 synctest.Sleep 后仍然失败，我会按下面的顺序排查，而不是继续把等待时间从 20 毫秒改成 200 毫秒。

第一，确认测试真的在 bubble 内。synctest.Sleep 和 synctest.Wait 不能在 bubble 外调用；测试入口应是 synctest.Test(t, func(t *testing.T) { ... })，并且被测 goroutine 从这个函数内部启动。

第二，确认没有把 goroutine 从 bubble 外启动。在测试函数外启动的后台任务不属于当前 bubble，Sleep 不负责等待它。把任务启动、停止和结果读取收拢到同一个测试生命周期里，必要时用 t.Cleanup 释放资源。

第三，检查真实网络或外部进程。网络读写可能被进程外的事件唤醒，runtime 无法把它当作 durable blocked。网络客户端测试可以注入内存连接或 fake transport；不要指望虚拟时钟让真实服务器按测试时间推进。

第四，清理不会自动结束的任务。synctest.Test 返回前会等待 bubble 内 goroutine 退出。后台循环、未关闭的 channel 或没有响应取消信号的 worker，通常应该通过 context.WithCancel 建立退出路径。

按 Go 版本选择最小写法

如果项目使用 Go 1.27 或更高版本，优先写 synctest.Sleep。如果项目仍在 Go 1.25 或 Go 1.26，可以保留组合写法：

// Go 1.25/1.26 的兼容写法：先推进虚拟时间，再等待 bubble 收敛。
time.Sleep(20 * time.Millisecond)
synctest.Wait()

不要为了兼容旧实验 API 重新设置 GOEXPERIMENT=synctest。Go 1.25 已将正式 API 放入标准库，旧实验 API 与当前 Test 入口不是同一套使用方式。升级时重点检查导入路径、Run 到 Test 的变化，以及测试是否把所有后台任务放在 bubble 生命周期内。

最后用一张清单判断是否真的稳定

• 测试入口是 synctest.Test，不是在 bubble 外调用 Sleep。
• Go 1.27+ 使用 synctest.Sleep；旧版本用 time.Sleep 加 synctest.Wait。
• 被测 goroutine 从当前 bubble 启动，断言发生在等待之后。
• 真实网络、外部进程和 bubble 外任务都有明确的 fake、注入或退出处理。
• 测试结束前所有 worker 都能响应取消并退出。

对这个问题来说，稳定性不是把 Sleep 的数字调大，而是让“时间推进、后台 goroutine、断言读取”处在同一个可控边界里。synctest.Sleep 能补齐其中的时间与同步关系，但不会替代测试隔离、I/O 注入和生命周期清理。

相关问题

synctest.Sleep 和 time.Sleep 有什么区别？前者在 bubble 中等待虚拟时间并等待其它 bubble goroutine 稳定阻塞，后者只表达时间等待。

为什么用了 synctest.Sleep 还会卡住？常见原因是 bubble 内存在永远不会退出的 goroutine，或代码等待真实 I/O；应先处理退出路径和 I/O 隔离。

synctest.Wait 能不能替代 Sleep？不能。Wait 不主动推进虚拟时间；如果任务依赖未来的 timer，需要先推进时间，Go 1.27 通常直接使用 Sleep。