Go 测试偶发失败怎么办：用 -shuffle 找出顺序依赖

同一组 Go 测试在本地大多时候跑着都正常，放到 CI 环境里却时不时失败，先别急着把锅全推给“环境不稳定”。出现这类问题的高频原因是测试之间偷偷共享了状态：前一个测试改了全局变量、临时文件、环境变量、数据库记录或者默认配置，后一个测试刚好依赖了前者遗留的结果才可以正常运行。Go 自带的随机顺序测试功能，就能更早把这类藏得很深的依赖问题挖出来。

先判断：这是不是顺序依赖

如果单独运行某个测试全程正常，但是跑完整包、并行跑测试或者上传到 CI 之后偶尔失败，基本可以怀疑不同测试之间出现了互相影响。先去翻失败日志，确认异常现象是不是和前一个测试的行为有关，比如配置值不对、记录数量多了一条、临时文件夹里留着旧文件，或是环境变量没有被正确恢复到初始状态。之后再用随机顺序测试，确认问题可以被稳定触发。

go test -shuffle=on ./...

Go 官方命令文档里说明，-shuffle 会随机打乱测试和基准测试的运行顺序；设置为 on 时会用系统时钟作为随机种子，运行结束后会输出这个种子值。别只截取最后一行的失败报错信息，这个种子是后续复现问题的关键依据。

拿到种子后，先把失败顺序复现出来

随机运行触发失败之后，用输出里的整数种子再次执行测试。固定种子不会帮你自动修好问题，但是能让整个团队在完全一致的测试顺序下调试、排查、编写回归测试，不用每次都靠碰运气等错误复现。

go test -shuffle=12345 ./...

复现的时候可以先缩小范围到出问题的单个测试包；如果问题还是很难稳定触发，再排查测试是不是读写了时间、网络、数据库或者其他跨进程的共享资源。随机顺序功能只能覆盖测试的启动顺序，不能替代并发测试、竞争检测或是外部依赖的隔离工作。

最常见的四类共享状态

修复时把初始化和清理放回测试自身

好的测试既能独立运行，也能以任意顺序正常运行。每个测试启动时，要自己创建需要的输入、对象、临时资源，运行结束后自己完成释放或者状态恢复；不要依赖其他测试提前帮你生成好数据，也不要让一个测试的通过前提是前面某几个测试已经执行过。如果真的需要共享成本很高的资源，要明确标注它的只读边界，在测试套件层面统一管理它的生命周期。

func TestLoadConfig(t *testing.T) {
    t.Setenv("APP_MODE", "test")
    dir := t.TempDir()

    cfg, err := LoadConfig(dir)
    if err != nil {
        t.Fatal(err)
    }
    _ = cfg
}

常见问题

固定种子跑通了，是不是就可以合并代码？

不够。固定种子只能证明某一种特定顺序下测试是正常的。修复完成后还要多次随机运行测试，再结合包级全量测试、并发相关检查和 CI 运行结果，确认测试之间不会再互相污染。

所有项目都要一直开启随机顺序测试吗？

它更适合作为 CI 的补充检查项，或者排查偶发失败的专用工具。要不要长期开启要看团队的维护成本预算，但对共享状态比较多的包，定期跑随机顺序测试很有价值。

随机顺序测试和数据竞争检测是一回事吗？

不是。随机顺序测试主要用来发现测试生命周期和共享状态的问题；数据竞争检测关注的是并发场景下的不安全读写。两者解决的问题不一样，可以互相补充。

测试偶发失败最容易出现的误区就是“再跑一次就好了”。把随机顺序、种子复现、状态隔离和修复后复验做成固定流程，就能把藏得很深的顺序依赖问题，变成可定位、可回归的常规问题。