Go testing/synctest 里 t.Skip 为什么仍显示 PASS：bubble 与测试结果边界

并发测试依赖某个可选环境时，我们常在条件不满足时调用 t.Skip。但 Go 官方仓库 2026 年 9 月 1 日提交的问题 #81261 给出一个特殊现象：在 testing/synctest 的 bubble 内调用 t.Skip，内层 goroutine 会退出，外层测试却可能继续并最终显示 PASS。这个问题目前仍是“需要调查”的开放状态，不能把它当成已经确认的语言规则。

先分清 outer *testing.T 与 bubble *testing.T

synctest.Test 会在隔离的 bubble 中运行回调，并把一个新的 *testing.T 传给回调。官方文档还明确限制：bubble 内的这个测试对象不能调用 T.Run、T.Parallel 和 T.Deadline。因此，代码里虽然两个参数都常写成 t，它们并不是同一个状态载体。

官方问题中的复现先进入 synctest.Test，再在回调参数上调用 t.Skip。Skip 等价于记录日志后调用 SkipNow；后者通过 runtime.Goexit 结束当前测试 goroutine。于是内层后续语句不会运行，但外层函数仍可能从 synctest.Test 返回后继续。

为什么日志最终可能显示 PASS

问题报告展示的关键证据是：bubble *testing.T 已进入 SKIP 状态，outer *testing.T 的 Skipped() 却仍为 false。外层没有收到失败或跳过标记，后续也没有其他断言失败时，测试框架便可能把外层结果记为 PASS。

这里要保留一个边界：#81261 目前标记为 BugReport 与 NeedsInvestigation，没有里程碑，也没有关联修复。因此只能确认报告中的 gotip 复现，不能断言所有 Go 版本都存在同样行为，更不能预告具体修复版本。

问题确认前怎么写更稳妥

如果跳过条件在进入 bubble 前就能判断，把检查放到外层：

func TestWorker(t *testing.T) {
    if os.Getenv("TEST_BACKEND") == "" {
        t.Skip("TEST_BACKEND is not configured")
    }

    synctest.Test(t, func(t *testing.T) {
        // 这里只测试并发与虚拟时间逻辑。
    })
}

这样 SKIP 状态直接写入 outer *testing.T，测试报告与 CI 统计更一致。若条件只能在 bubble 内得知，不要悄悄依赖内层 t.Skip 改变外层状态；可以把条件探测提前，或把结果返回给外层后再决定失败、跳过还是继续。升级 gotip 或后续 Go 补丁时，再用一个最小回归用例核对 Skipped() 与命令输出。

常见问题

这是不是 testing/synctest 的确定行为？

目前不能这样下结论。官方问题仍处于调查阶段，文章描述的是公开复现和现阶段可采用的防误判写法。

内层 t.Skip 之后的代码还会运行吗？

当前复现中不会，SkipNow 会结束 bubble 内的测试 goroutine；需要警惕的是外层测试状态可能仍未变成 SKIP。