Go synctest 怎么测并发超时：fake time、Wait 与死锁边界

并发测试最麻烦的地方，往往不是把 goroutine 启动起来，而是很难稳定地等到“应该发生”的那一刻：定时器还没触发，测试先结束了；把 sleep 加长，CI 又变慢；把 sleep 缩短，偶发失败就回来。Go 1.25+ 的 testing/synctest 把这段等待改成了可控的 fake time 和 bubble。

需要验证异步回调、超时和取消路径时，优先把被测 goroutine 放进 synctest.Test，用 synctest.Wait 等待稳定点，再用 time.Sleep 推进虚拟时间；网络、外部进程和测试外启动的 goroutine 仍应替换或移出 bubble。

先把普通 sleep 测试换成一个最小 bubble

假设业务函数会在 30 秒后刷新缓存。传统写法通常是启动函数、睡几十毫秒，再看回调有没有到达。这既没有表达“时间已经过去”，也无法证明 goroutine 是否已经进入等待。

package refresh

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

func refreshAfter(ctx context.Context, delay time.Duration, done chan

这里的 time.Sleep 不会真的让测试停 30 秒。先调用 synctest.Wait，可以让测试跑到一个明确的稳定点；随后虚拟时钟推进，timer 才有机会发送结果。把两个动作写开，失败时更容易判断是提前触发，还是根本没有进入 bubble。

Test 和 Wait 分别解决什么问题

synctest.Test 负责边界：它让回调和其内部启动的 goroutine 处于同一个隔离环境，并把测试的 *testing.T 传进这个环境。synctest.Wait 负责时机：它等待 bubble 内的 goroutine 都阻塞在彼此可观察的同步点。

两者不能互换。只有 Wait 没有 bubble，无法提供 fake time；只有 Test 而没有稳定点，测试仍可能在异步回调真正运行前就做断言。一个实用顺序是：

1. 在 synctest.Test 中创建 context、channel 和被测 goroutine。
2. 调用 synctest.Wait，确认初始状态已经稳定。
3. 用 time.Sleep 推进虚拟时间，或触发取消。
4. 再次 synctest.Wait，再读取结果并断言。

超时与取消：先测成功，再测停机

真实服务通常同时拥有两个出口：timer 到期后完成，context 取消后放弃。只覆盖成功回调，会把最容易泄漏 goroutine 的路径留在测试之外。

func TestRefreshCancel(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        ctx, cancel := context.WithCancel(context.Background())
        done := make(chan string, 1)
        go refreshAfter(ctx, time.Hour, done)

        synctest.Wait()
        cancel()
        synctest.Wait()

        select {
        case value := 

取消后再次 Wait 的意义，不只是等待断言条件成立，也是让 bubble 有机会暴露没有退出的后台 goroutine。若根测试函数返回时仍有无法收敛的工作，问题应该回到被测代码的退出路径，而不是继续增加 sleep。

方案边界：哪些依赖要替换，哪些现象不要硬测

synctest 适合测试由 Go goroutine、channel、timer 和 context 组成的闭环。它不应该成为把所有真实依赖塞进测试的理由。

• 真实网络：换成内存实现或可控的 fake transport，测试请求重试和超时决策；网络本身另做集成测试。
• 外部进程：不要让 bubble 等待一个测试外的进程退出，命令执行边界应由独立测试覆盖。
• 全局后台 goroutine：把启动动作收进被测函数，并提供明确的取消入口，否则 bubble 无法代表完整生命周期。
• 第三方时钟：若库内部不使用标准 time，不要假设它会自动跟随 fake time，必要时注入时钟接口。

这也是架构上的取舍：单元测试追求可重复的因果链，集成测试再负责真实网络、文件系统和进程调度。边界切清楚，测试才不会既慢又不稳定。

遇到 Wait 卡住时，按这条路径定位

第一次看到 bubble 卡住，不要先把 Wait 删除。先区分三种情况：

1. timer 仍在等待虚拟时间：确认根测试函数没有提前返回，并检查是否真的执行了推进时间的语句。
2. goroutine 等外部事件：检查是否调用了网络、进程或测试外创建的 channel；把依赖替换成 bubble 内可控对象。
3. 取消没有传播：检查 select 是否同时监听 ctx.Done()，以及关闭 channel 的责任是否明确。

如果怀疑是停机顺序，给每个退出分支留下一个可观察结果，例如 buffered channel、状态字段或错误值。不要靠日志出现与否判断 goroutine 已经结束；日志只能说明某个点被执行，不能说明 bubble 已经收敛。

常见问题

Go 1.24 还能直接使用 synctest 吗？

Go 1.24 中它还是实验 API，需要启用 GOEXPERIMENT=synctest，而且函数名和 1.25 的稳定 API 不同。面向新代码时，先确认项目最低 Go 版本，再决定是否使用稳定的 synctest.Test。

synctest.Wait 会不会替我等待任意 goroutine？

不会。它只关注当前 bubble 中的 goroutine；测试外部启动的 goroutine、网络或进程都不属于这个隔离范围。

为什么推进了时间，timer 还是没有结果？

先确认 timer 所在 goroutine 已进入 bubble，并在推进后再次调用 synctest.Wait。如果回调还依赖外部事件，单纯推进标准库时间不会让那个依赖自动完成。

生产代码需要为了 synctest 改成特殊写法吗？

通常不需要。优先保留标准的 context、time、channel 组合；只有依赖第三方时钟、外部网络或不可控后台任务时，才通过接口或 fake 实现建立测试边界。

把并发测试拆成“进入 bubble—等待稳定—推进时间或取消—再次等待—断言结果”五个动作，通常就能删掉大部分猜测式 sleep。剩下无法自包含的部分，应该明确归入集成测试，而不是让单元测试承担真实环境的不确定性。