Go go test -shuffle 返回错误时怎么区分原因

go test -shuffle 返回错误时，先看有没有出现 -test.shuffle 的 seed 行：没有，优先排查参数解析、编译或 go vet；有，再按测试失败处理。这个判断比看到“随机顺序”就直接改测试更可靠，因为前两类错误根本还没有运行测试函数。

一句话结论：把输出按“命令入口、测试包构建、测试二进制”三层分流；只有最后一层才需要用 seed 固定顺序重跑。

实际排查时先保存完整日志和 seed，再决定修命令、修构建，还是修测试之间的共享状态。

先看失败输出落在哪一层

-shuffle 支持 off、on 或整数 seed。写成不支持的值时，go 命令会在测试二进制启动前报参数错误；这类输出通常只有 usage 和 invalid value，不会有 -test.shuffle N。

参数错误与构建失败不要混成顺序问题

例如把参数写成字符串 random，失败原因是命令行值不合法；改成 -shuffle=on 才会让测试运行。若参数正确但包无法编译，或默认 vet 检查先报错，输出常见 FAIL 与 setup failed，仍然没有可复现的测试顺序。

# 参数合法后才进入测试二进制；on 使用系统时钟生成 seed
go test -shuffle=on ./...

# 直接指定整数，便于把同一顺序交给 CI 或同事复现
go test -shuffle=314159 -count=1 ./...

# 只用于确认是否被默认 vet 拦住；不要把它当成长期修复
go test -shuffle=314159 -vet=off ./...

-vet=off 只能帮助确认阻塞位置，不能替代修复 vet 报错。若关闭后出现了 -test.shuffle，说明先前失败在构建检查层；之后仍应回头修正代码或检查配置。

固定 seed 把偶现失败变成可重放

当日志已经打印 -test.shuffle N，说明测试二进制启动了。复制这个整数，比再次使用 on 更适合定位，因为 on 每次可能产生不同顺序。

# 第一次运行：让 Go 生成并输出一个 seed
go test -v -shuffle=on ./internal/cart

# 第二次运行：把失败时记录的 N 原样带回去
go test -v -shuffle=314159 ./internal/cart

# 调试共享状态时关闭缓存，避免把成功缓存误判为修复
go test -v -shuffle=314159 -count=1 ./internal/cart

固定 seed 后仍失败，优先检查包级可变变量、测试写入的临时文件、全局环境变量、清理函数顺序，以及调用 t.Parallel() 的测试是否共享资源。-shuffle 改的是测试和 benchmark 的执行顺序，不会自动替你制造隔离。

按证据收敛修复范围

建议保留三份最小证据：完整命令、首次出现的错误行、-test.shuffle seed。然后按下面顺序处理：

1. 没有 seed：修参数、编译错误或 vet，直到测试二进制能启动。
2. 有 seed 且稳定失败：只运行失败包，检查测试之间的共享状态和清理边界。
3. 固定 seed 不再失败：换两个明确整数重复运行，并把可疑资源改为每个测试独立创建。
4. CI 与本地结果不同：记录 Go 版本、操作系统、环境变量和包路径，先缩小环境差异。

不要仅仅把 -shuffle=off 写进 CI 来“修复”失败；它最多隐藏顺序依赖。真正稳定的测试应能在任意合理顺序下保持隔离，固定 seed 只是定位工具。

常见追问

为什么只看到 FAIL，却没有 shuffle seed

先看 FAIL 前面是否有 setup failed、编译错误或 vet 输出；如果测试二进制没有启动，就不会打印运行阶段的 seed。

固定 seed 后还需要加 -count=1 吗

排查阶段建议加。它用于避免成功测试结果被缓存，不能替代 seed，也不能解决共享状态本身。

排查清单：先分层，再记 seed；先确认测试已启动，再追顺序；最后修隔离，不用关闭 shuffle 掩盖问题。