testing/synctest 中 channel 阻塞状态的判断

我第一次用 testing/synctest 排查并发测试时，很容易把“某个 goroutine 当前停住了”和“synctest 能确认它已经稳定阻塞”混为一谈。真正有用的判断标准不是调用栈看起来像不像卡住，而是这个阻塞是否只能由同一个 bubble 里的事件解除。

先给结论：同一个 synctest bubble 内创建的 channel 上，发送或接收如果处于阻塞状态，通常会被视为 durable blocking；nil channel 的发送和接收也属于这一类。反过来，bubble 外创建的 channel，以及网络等可能被外部事件唤醒的 I/O，不能简单当成 durable blocking。状态检查应放在 synctest.Wait() 之后。

先把阻塞状态放进 synctest 的 bubble

testing/synctest 的思路是把并发测试放入一个隔离的 bubble。Go 1.25 中公开的入口是 synctest.Test，它执行测试函数并让 bubble 内的 goroutine 使用虚拟时间；synctest.Wait 则等待 bubble 中的后台活动完成，直到所有相关 goroutine 都在等待 bubble 内的其他 goroutine，或者到达可以推进时间的状态。

这也是我写这类测试时最先调整的一步：不要先启动 goroutine，再用真实时间的 time.Sleep 猜它是否跑完，而是把创建、启动和观察都放到同一个测试 bubble 里。

package synctestdemo

import (
    "testing"
    "testing/synctest"
)

func TestWorkerReachesChannelWait(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        ready := make(chan struct{})
        state := "not-started"

        go func() {
            // 先写入状态，再等待同一个 bubble 内的 channel 事件。
            state = "waiting"
            

这里的关键不是 Wait 让任意 goroutine 都“自动完成”，而是它把 bubble 内的后台活动推进到一个确定的边界。只有在这个边界之后读取 state，断言才不会依赖调度器恰好把多少时间片分给了 worker。

沿 channel 的创建位置判断 durable blocking

我会沿着 channel 的生命周期做判断：谁创建它、创建发生在哪个 bubble、阻塞的一方是否也在这个 bubble 中。channel 在 bubble 内创建时，运行时能够知道它的发送接收关系属于这个隔离环境；如果它暂时没有匹配的发送方或接收方，阻塞可以被归入 bubble 内的稳定状态。

nil channel 是另一个容易漏掉的特例。对 nil channel 发送或接收永远不会匹配成功，因此它属于 durable blocking；但这不代表在业务测试里应该随手使用 nil channel。它更适合用来表达一个明确的“永不触发”分支，若是误把普通 channel 变量留成 nil，测试可能以一种看似稳定、实际错误的方式停住。

func TestChannelSourceMatters(t *testing.T) {
    // bubble 外的 channel 不应拿来表达 bubble 内部通信。
    outside := make(chan int)

    synctest.Test(t, func(t *testing.T) {
        inside := make(chan int)
        state := "not-started"

        go func() {
            // 这个 channel 在 bubble 内创建，接收阻塞属于内部等待。
            state = "waiting-inside"
            

还有一个边界必须记住：在 bubble 外创建的 channel，不能当作 bubble 内部的可控同步点。synctest 对这类操作的设计目标是避免把可能由外部 goroutine 或外部事件解除的等待误判为 durable blocking；如果把外部 channel 当作内部 channel 使用，轻则 Wait 的时机和预期不一致，重则触发运行时对 bubble 边界的限制。

用 Wait 观察 goroutine 到达稳定阻塞点

判断 channel 阻塞时，我通常把断言拆成“进入等待”和“解除等待”两段。第一段让 worker 在 channel 接收处停住，调用 synctest.Wait 后断言中间状态；第二段由 bubble 内的发送或关闭操作解除，再次调用 Wait，最后断言完成状态。这样能把生命周期中的两个状态分开，不会因为一条断言太早读取共享变量而产生偶发失败。

func TestSendThenReceive(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        messages := make(chan string)
        state := "waiting-for-message"

        go func() {
            // 无缓冲 channel 需要同一个 bubble 内的发送方配对。
            msg := 

这个模式里，Wait 的价值是收敛事件顺序，不是提供一个通用的“等任意异步工作完成”按钮。若 worker 在执行 CPU 计算、等待外部网络、获取 bubble 外持有的资源，或者根本没有到达一个 durable blocking 点，Wait 的行为就不能按 channel 示例套用。

用状态流排查 Wait 不返回或提前返回

当测试卡在 Wait，我会先画出四个节点：channel 创建、goroutine 启动、阻塞点、解除事件。然后逐个检查节点是否在同一个 bubble 中。常见问题不是 channel 语法，而是创建位置被挪到了测试外层，或者解除事件实际上依赖了网络、定时器之外的外部资源。

可以按下面这条顺序缩小范围：

1. 确认测试使用的是 Go 1.25 之后的 synctest.Test API，避免把 Go 1.24 实验版的 Run 用法混进来。
2. 确认 channel 在 bubble 内创建，并且发送方、接收方和状态变量的访问关系符合测试设计。
3. 在 goroutine 到达 channel 操作后调用 synctest.Wait，再读取中间状态。
4. 用 bubble 内事件解除阻塞，再调用一次 Wait，检查最终状态。
5. 若仍不符合预期，暂时把外部 I/O、共享锁和额外 goroutine 拆掉，确定问题属于 channel 边界还是业务逻辑。

处理外部唤醒和 I/O 边界

synctest 的 durable blocking 定义强调“只能由 bubble 内的其他 goroutine 解除”。普通网络读写即使当前没有数据，也可能被操作系统、另一个进程或 bubble 外的写入唤醒，因此不能把它们和 bubble 内 channel 接收视为同一种阻塞。文件 I/O、系统调用、外部锁也要用同样的思路审视。

如果测试目标是网络协议或客户端状态机，我会把网络层换成可控的 fake 实现，或者使用内存连接把通信事件显式放进测试流程；不要指望 Wait 替你等待真实网络。测试仍然可以验证业务状态，但“何时收到字节”必须由 bubble 内可控的事件驱动。

func TestExternalBoundaryIsExplicit(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        events := make(chan string)
        got := "waiting"

        go func() {
            // 业务 goroutine 只依赖 bubble 内的事件，不直接读真实网络。
            event := 

最后再总结一次：判断 channel 阻塞状态时，先看创建位置，再看阻塞是否只依赖 bubble 内事件，最后把断言放到 synctest.Wait 建立的状态边界之后。这样写出的测试不依赖固定 sleep，也不会因为一个 goroutine 暂时停住就错误地认为整个并发流程已经稳定。

常见问题

channel 在 bubble 外创建，为什么不能直接拿进 synctest.Test？

因为 synctest 需要区分 bubble 内部可控事件和 bubble 外部可能发生的唤醒。外部创建的 channel 不属于当前隔离环境，不能用来推断内部 goroutine 已经进入 durable blocking；应在 bubble 内创建测试用的同步 channel。

synctest.Wait 是不是等所有 goroutine 返回？

不是。它等待 bubble 中的 goroutine 进入可判定的阻塞状态，或完成相应的后台活动收敛。一个 goroutine 若正在计算或等待外部事件，不能只靠 Wait 把它变成“已完成”。

为什么用 time.Sleep 代替 Wait 容易出现偶发失败？

真实 sleep 只提供时间长度，不保证目标 goroutine 已经执行到某个状态。Wait 面向的是 bubble 的并发收敛点；将状态断言放在 Wait 后，测试才是在检查事件顺序，而不是猜测调度结果。