Go go test -shuffle 升级后行为变化怎么定位

Go 升级后，go test -shuffle 下的失败顺序或通过结果发生变化，最稳妥的定位方式不是先判断“新版本把测试改坏了”，而是先把随机性、缓存和测试共享状态拆开。先用 -shuffle=off -count=1 得到基线，再把一次随机失败的 seed 固定下来，最后缩小到具体测试和子测试。

只要能记录 Go 版本、测试包、shuffle seed 和是否绕过缓存，就能把“升级后偶发失败”变成同一个顺序可重复的排查对象。

官方地址：https://go.dev/doc/

Go 官方对 -shuffle 的定义包含 off、on 和整数 seed：关闭时不打乱；使用 on 时由系统时钟产生随机 seed；使用整数时固定这个 seed，并报告它以便复现。升级后行为看似变化，通常要先确认到底是随机顺序暴露了测试依赖，还是工具链本身真的改变了测试执行条件。

先把升级后的运行条件固定下来

第一步记录实际参与测试的 Go 版本和模块状态。不要只看开发机上安装过哪个版本，因为 CI、容器或 IDE 可能调用另一份 go。版本信息应和失败日志放在同一条记录里，后面比较时才不会把环境差异误认为 shuffle 差异。

# 记录当前测试进程实际使用的 Go 版本
go version

# 记录模块解析结果，避免升级后依赖图悄悄变化
go list -m all

# 先关闭随机化并绕过测试缓存，建立可比较的基线
go test ./... -shuffle=off -count=1

这里的 -count=1 只负责减少测试缓存对观察结果的干扰，不等于修复问题。若关闭随机化后仍然失败，优先比较依赖、环境变量、时区、文件系统或测试数据；若只有 shuffle 开启时失败，继续检查顺序依赖。

升级后先比较哪几种运行方式

排错时可以把四种方式当成一个小型对比矩阵。shuffle=off 是顺序基线，shuffle=on 用于发现不同执行顺序下的脆弱测试，固定整数 seed 用于回放某一次失败，count=1 用来避免缓存掩盖变化。它们解决的问题不同，不能只反复执行同一条随机命令。

如果 -shuffle=on 失败但固定 seed 无法复现，先确认命令、包集合、Go 版本和测试数据完全一致。随机 seed 只是执行顺序的一部分，外部时间、临时目录或并发资源也可能参与结果。

如何记录 seed 并回放同一次失败

使用 on 时，把测试输出中报告的 seed 保存下来；随后把它替换成整数。回放时不要同时改动测试代码、包范围或环境变量，否则即使 seed 相同，执行条件也不再相同。

# 用随机 seed 扫描顺序依赖，并保留完整输出
go test -v ./path/to/pkg -shuffle=on -count=1 2>shuffle.err | tee shuffle.log

# 把日志里报告的整数 seed 替换到这里，复现同一顺序
go test -v ./path/to/pkg -shuffle=12345 -count=1

# 只跑一个顶层测试，继续缩小复现范围
go test -v ./path/to/pkg -run '^TestAccountState$' -shuffle=12345 -count=1

固定 seed 后，如果每次都在同一个测试附近失败，顺序依赖的可能性很高。若失败位置仍然漂移，检查测试是否调用了 t.Parallel、是否依赖当前时间或随机数据，以及命令是否确实只针对同一个包。

子测试顺序变化时检查什么

顶层测试稳定并不代表子测试安全。下面的示例把测试用例放进 t.Run，并显式初始化每个用例需要的状态。实际项目中，初始化应尽量放在子测试内部；如果必须修改进程级状态，就用清理函数恢复。

package account_test

import "testing"

func TestAccountState(t *testing.T) {
	// 每个用例拥有自己的输入，避免依赖上一个子测试留下的值。
	cases := []struct {
		name string
		want string
	}{
		{name: "new", want: "new"},
		{name: "paid", want: "paid"},
	}

	for _, tc := range cases {
		tc := tc // 固定本轮子测试要使用的用例副本。
		t.Run(tc.name, func(t *testing.T) {
			// 在子测试内重新创建状态，不读取其他用例的全局残留。
			state := newAccountState()
			got := state.Status()
			if got != tc.want {
				t.Fatalf("status = %q, want %q", got, tc.want)
			}
		})
	}
}

// 示例占位函数表示业务层应返回新状态，而不是复用可变单例。
func newAccountState() *accountState { return &accountState{status: "new"} }

type accountState struct{ status string }

func (s *accountState) Status() string { return s.status }

示例的重点不是某个业务结构，而是每次运行都重新建立输入和状态。若原测试通过包级变量、环境变量、默认配置或共享临时目录传递信息，shuffle 只是在更早的位置暴露了这种隐式依赖。

共享状态为什么会让升级像是改变了行为

常见的泄漏来源包括全局 map、os.Setenv、当前工作目录、固定文件名、共享数据库记录和没有关闭的后台 goroutine。某个 Go 版本或依赖升级后，测试顺序、调度时机或清理时机的细微变化，都可能把原本隐藏的残留暴露出来。

处理方式是让测试拥有明确的生命周期：在测试开始时初始化，在测试结束时清理，并把清理注册在最接近修改动作的位置。对于环境变量尤其要注意，测试过程会影响整个进程；如果测试需要并行运行，就不能随意在并行测试中修改进程级环境。

func TestWithTempConfig(t *testing.T) {
	// 用测试专属目录隔离文件，避免固定路径被其他测试复用。
	dir := t.TempDir()

	// 只在本测试范围内设置环境变量，测试结束后自动恢复旧值。
	t.Setenv("APP_CONFIG_DIR", dir)

	// 如果还修改了自定义全局状态，应注册对应的恢复动作。
	old := globalMode
	globalMode = "test"
	t.Cleanup(func() {
		globalMode = old // 先恢复全局状态，再让后续测试继续运行。
	})

	// 业务断言应只依赖本测试创建的目录和状态。
	if got := loadMode(); got != "test" {
		t.Fatalf("mode = %q, want test", got)
	}
}

如果升级后失败只在 -shuffle 开启时出现，优先沿着“谁写入、谁读取、谁清理”的链路排查，而不是给命令增加更多随机重试。重复随机运行只能增加暴露概率，不能说明哪个测试留下了脏状态。

用一组矩阵命令确认是不是工具链差异

当固定 seed 已能稳定重现后，再比较旧 Go 与新 Go、关闭 shuffle 与固定 seed 四个维度。每次只改变一个维度，并把命令、版本、seed 和结果摘要放在一起。这样才能回答“升级改变了行为”究竟是新工具链直接导致，还是旧测试本来就依赖未定义的执行顺序。

# 新工具链的非随机基线：先判断测试本身是否已经失败
go test ./... -shuffle=off -count=1

# 新工具链回放同一个顺序：确认问题是否稳定
go test ./... -shuffle=12345 -count=1

# 只比较一个包，减少并行包输出对判断的干扰
go test ./internal/account -v -shuffle=12345 -count=1

# 每次切换工具链后都重新记录版本，避免把环境差异混在结论里
go version

结果可以按下面的规则解释：

• 关闭随机化也失败：先处理测试数据、依赖或环境变化，shuffle 不是首要嫌疑。
• 只有随机顺序失败且固定 seed 可回放：优先修复共享状态、清理和测试隔离。
• 同一 seed 只在新工具链失败：保留最小复现包、版本和 seed，再进一步查看测试 API 或依赖的兼容性变化。
• 每次失败 seed 都不同且无法回放：先固定包范围、环境和输入，再讨论并发或时间依赖。

常见问题

-shuffle=on 失败是不是 Go 新版本的 bug？ 不能直接这样判断。它首先说明某种执行顺序触发了差异，只有在最小复现、固定 seed 和版本矩阵都完成后，才适合提交工具链回归问题。

为什么固定 seed 还会出现不同结果？ seed 只固定 shuffle 的顺序，不能固定时间、网络、并发调度、外部数据库或随机输入。先把这些外部条件替换为测试专属资源。

可以一直加 -count=1 吗？ 定位阶段可以用它排除缓存干扰；修复完成后仍要按项目正常命令运行，确认测试缓存和 CI 行为没有被误解。

应该把所有测试都改成串行吗？ 不建议。先修复测试之间的隐式依赖，再保留真正有价值的并行测试；为了躲开 shuffle 而全局禁用并行，会掩盖资源隔离问题。