Go 测试并发代码怎么稳定复现：t.Parallel、竞态检测与失败证据

并发测试最麻烦的地方，不是偶尔失败，而是失败一次后再也跑不出来。Go 里把子测试改成 t.Parallel() 只是改变调度时机，不能替你隔离共享变量；要稳定复现，应该把测试拆成明确的状态变化，再用 go test -race 固定留下证据。

先用可重复的输入放大竞态窗口，再用 race detector 证明是否存在未同步读写；不要把“这次没失败”当成并发安全。

先把“偶尔失败”变成可观察的测试

假设一个批量聚合函数会把每个任务的结果写入共享计数器。生产代码可能用了锁，但测试夹具为了省事直接复用了普通变量，结果是 CI 上偶发少算，开发机却一切正常。

package counter

import "testing"

func TestCountParallel(t *testing.T) {
    total := 0
    for i := 0; i 

这段测试同时踩了两个边界：子测试声明并行执行，父测试却在子测试真正恢复前就继续向下检查 total。它想验证的成功结果是 total = 8；即使把断言放到看似合适的位置，多个子测试对 total++ 的读改写仍然不是原子操作。

三种运行方式，证据强度并不一样

我通常先把同一测试分别跑三次。串行运行用于确认断言和业务意图，重复运行用于扩大调度差异，竞态检测则用于回答“是否存在未同步访问”这个更具体的问题。

其中 -count=100 只是重复执行测试，不能替代 -race。反过来，race detector 报告的是访问同步问题，未必能发现“结果应该是 8 却算成 7”这类业务断言错误。

用 t.Parallel 的真实调度边界重写夹具

t.Parallel() 调用后，当前子测试会暂缓，直到父测试返回或父测试不再阻塞并行子测试。为了让每个子测试拥有自己的输入，可以把结果通过局部变量传回父测试，而不是让多个闭包直接改同一个 total。

func TestCountParallelSafe(t *testing.T) {
    cases := []struct {
        name string
        want int
    }{
        {name: "first", want: 1},
        {name: "second", want: 1},
        {name: "third", want: 1},
    }

    for _, tc := range cases {
        tc := tc
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            got := 1
            if got != tc.want {
                t.Fatalf("got %d, want %d", got, tc.want)
            }
        })
    }
}

这里的关键不是“并行一定更快”，而是每个子测试只读自己的 tc 和 got。如果测试必须汇总结果，就让被测代码提供并发安全的接口，或在测试结束后通过 channel / WaitGroup 明确收集，而不是偷偷写共享整数。

如何保存一次可回归的失败证据

把命令和输出一起保存到 CI 工件中，后续修复才能比较前后差异。一个实用的最小组合是先跑断言，再跑竞态检测：

go test -run '^TestCountParallel$' -count=100 ./...
go test -race -run '^TestCountParallel$' -count=1 ./...

第一条命令如果出现 total = 6, want 8，说明结果断言已捕获异常；第二条命令若出现 WARNING: DATA RACE，则给出了访问栈和冲突位置。两者都通过时，也只能说明这组输入和这次运行没有发现问题，不能把测试结果扩大成全局保证。

什么时候不该使用 t.Parallel

如果子测试会修改进程级环境变量、当前工作目录、全局注册表、共享临时目录，或者依赖固定的日志顺序，就先保持串行。可以先让测试稳定表达一个业务断言，再针对纯输入型用例引入并行；为了追求速度把污染扩散到多个子测试，排错成本通常更高。

相关问题

为什么 -count=100 仍然可能一次都复现不了？

调度窗口、机器负载和编译器行为都可能不同。它能放大概率，不能穷举时序；要判断数据竞争，仍应运行 -race。

闭包里的 tc := tc 还需要吗？

当循环变量会被多个子测试异步读取时，保留局部副本更稳妥。它把每个子测试绑定到自己的输入，避免测试意图依赖循环变量的生命周期。

race detector 通过就代表业务结果正确吗？

不是。它主要检查未同步的内存访问；返回值、顺序、超时和资源释放仍要靠明确断言与独立测试覆盖。

最后的检查清单

• 先确认测试失败是否来自真实断言，而不是父测试过早结束。
• 并行子测试不共享可变输入；必须共享时使用明确的同步协议。
• 保存 -count 和 -race 的完整输出，修复后用同一命令回归。