Go 1.25 testing/synctest 怎么写并发测试：用虚拟时间替掉 time.Sleep

写并发测试的时候，很多人都碰到过这类糟心？不对，哦不对不能用糟心，改成写并发测试的时候，最容易出问题的一类代码通常是这么写的：先启动后台goroutine跑任务，time.Sleep(50 * time.Millisecond)，再去校验执行结果。开发机器空载跑起来可能只是速度慢一点，等CI环境负载高了，随时可能随机出现偶发失败。Go 1.25已经把testing/synctest正式纳入标准库，测试逻辑可以跑在完全受控的运行环境里直接推进虚拟时间，等所有后台任务全部停稳之后再检查状态。它没法替代所有集成测试，却特别适合把原先靠瞎等时间的单元测试，改成完全可复现的稳定验证逻辑。

你不用再靠经验猜Sleep要设多长，也不用为了适配CI环境反复把等待阈值调大，靠标准库提供的这套虚拟同步机制，就能把依赖墙上时钟的不稳定并发测试，改成执行速度快、结果完全可复现的稳定用例。

Go 1.25 为什么值得把旧的Sleep式并发测试迁过来

testing/synctest 在Go 1.24版本还属于需要手动开启的实验特性，到Go 1.25就直接作为正式标准库API对外提供了。它创建的受控环境会让里面所有跑的goroutine都使用虚拟时间，当这些goroutine全部卡在等待定时器、channel或者其他受控事件上的时候，测试时间可以直接往前跳，完全不用让进程真的等几十毫秒甚至几秒的真实时间。

别把它理解成可以让所有异步代码瞬间跑完的黑科技，它解决的只是测试内部完全可控的等待逻辑。如果后台逻辑卡在真实HTTP请求、磁盘IO，或者受控环境之外单独起的goroutine上，虚拟时间没办法帮你消除这些环节带来的不确定性。

虚拟时间为什么能完全收住等待时长

传统写法里先启动任务再Sleep，本质上是在赌“我设的50毫秒肯定够任务跑完”。受控环境直接把这个拍脑袋的判断，换成了两个可以明确观测的状态点：定时器有没有到期，后台goroutine是不是已经没有可以继续推进的工作。synctest.Wait 刚好就是用来检查后面这个状态点的。

有个边界很容易被忽略：Wait 只能代表当前所有待处理的任务都跑完了，不等于所有业务逻辑执行结果都是对的。它只说明受控环境里暂时没有活跃的待执行任务，缓存值是否正确、错误分支有没有覆盖、重复调用的表现是不是符合预期，还是要靠单独的断言和用例来覆盖。

用延迟写缓存复现一个典型的不稳定测试用例

下面这个示例模拟订单创建之后异步往内存缓存写数据的场景，实际业务里可能对应的是延迟聚合、延迟刷新、错误重试退避这类逻辑，示例里特意去掉了网络和数据库依赖，方便大家把注意力完全放在调度和时间的关系上。

type delayedCache struct {
    values map[string]string
}

func (c *delayedCache) putLater(key, value string) {
    go func() {
        time.Sleep(2 * time.Second)
        c.values[key] = value
    }()
}

如果直接在测试里写time.Sleep(2100 * time.Millisecond)之后再检查values，不仅测试跑的慢，后续维护还要不停调整等待时长，额外加很多没必要的成本。更合理的迁移方式，是把创建业务对象、启动后台任务和结果断言的所有逻辑，全部放到synctest.Test的闭包里面执行。

把延迟写缓存的旧测试改造成虚拟时间模式

func TestDelayedCachePut(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        cache := &delayedCache{values: make(map[string]string)}
        cache.putLater("order:42", "ready")

        synctest.Wait()
        if got := cache.values["order:42"]; got != "ready" {
            t.Fatalf("cache value = %q, want ready", got)
        }
    })
}

这个示例里，time.Sleep(2 * time.Second) 本身还是原来的业务代码，完全不用改动，只是测试环节再也不需要花两秒等真实时间跑完。后台goroutine卡在定时器休眠之后，受控环境可以直接把虚拟时间推进到定时器触发点，等它写完缓存整个环境重新回到静止状态，synctest.Wait 才会返回。

示例为了突出API用法写的比较短，但也暴露了一个很常见的问题：普通的map 做并发读写本身就会触发数据竞争。生产环境的代码本来就应该用互斥锁、channel或者其他并发安全的存储结构来处理，就算用上了虚拟时间，测试环节也要加上go test -race 去校验，不能直接跳过竞态检查步骤。

对比旧写法，哪些测试适合优先迁移

可以先挑三类测试动手改造：大量写了短Sleep的重试逻辑测试、依赖Ticker或者Deadline的状态机测试，还有需要等后台清理完全跑完的缓存测试。这些场景的共性是所有等待逻辑都跑在当前进程内部，执行结果也可以做明确的断言校验。

• 优先可以动手迁移的场景：定时关闭、错误退避重试、内存队列消费、延迟写入、靠channel协调的后台收尾逻辑。
• 暂时保留原有方案的场景：依赖真实数据库的逻辑、跨进程消息交互、外部HTTP服务调用、浏览器自动化，还有依赖真实时钟语义的端到端流程。
• 迁移完成之后要复查的点：删掉所有没必要写的长Sleep，确认错误分支的断言都保留，完整跑一遍带竞态检查的测试。

第一次接入的时候要避开三个容易踩的坑

第一，不要让受控环境里的代码偷偷依赖了环境外面的资源，如果测试偶尔卡住，先排查是不是有真实IO或者外部单独起的goroutine没有被替换掉。第二，别把Wait 当成随便什么时候都能调用的万能同步工具，它的设计目的就是用来等受控环境里的并发活动完全走到静止状态的时机。第三，升级之前先确认CI环境用的Go版本，Go 1.24的实验版API和Go 1.25正式发布的公开API不要混着用。

团队可以先挑一个跑的最慢、最容易出随机抖动的包做小范围试点，原先的基准数据先留好，测试总耗时降下来不代表测试覆盖就变好了，核心还是要看测试失败的时候能不能直接指向明确的状态和对应的断言。

延伸问答

testing/synctest 能把所有的 time.Sleep 都替换掉吗？

不行。它只适合测试内部可控的并发和时间推进逻辑，要等外部服务响应的场景，还是该用超时、Mock服务或者直接走集成验证流程。

还在用 Go 1.24 的项目能直接用这套特性吗？

Go 1.24里它还处于实验阶段，要按照当时的实验开关和API约束来用，打算长期落地这套能力的话，升级到Go 1.25之后再统一迁移会更稳妥。

用了Wait方法之后，还有必要断言channel结果或者缓存内容吗？

非常有必要。Wait只解决等待时机的问题，业务逻辑到底对不对，还是要靠结果值、错误返回、值域判断这些断言来确认。

为什么示例里还要建议跑 go test -race？

虚拟时间不会自动帮你消掉共享变量的读写竞争，竞态检查可以补上调度层面之外的内存访问合法性校验。

把并发测试里靠“多等一会儿”凑时长的逻辑，改成明确可观测的同步点，通常比不停调大Sleep的数值要可靠的多。针对完全受控的定时任务场景，testing/synctest 提供了一个足够轻量的切入方案，时间可以直接快进，校验的还是真实执行后的状态。