Go math/rand 并发测试结果不可复现的种子管理

math/rand 并发测试总是换结果，通常不是“种子没固定”，而是多个 goroutine 共享了同一个局部 Rand 或 Source。稳定做法是把基础种子和测试用例编号组合成派生种子，再为每个任务创建自己的 rand.New(rand.NewSource(seed))。这样调度顺序变化时，任务之间仍不会互相消耗随机状态。

官方文档：https://pkg.go.dev/math/rand

顶层 rand.Intn 等函数可以并发使用，但局部 Rand 和 Source 默认不应被多个 goroutine 同时调用。并发测试要复现失败，关键不是让所有任务共用一个全局种子，而是让每个任务拥有可记录、可重建的随机状态。

先确认：固定种子不等于固定并发顺序

单线程测试里，固定种子通常能得到同一段伪随机序列；并发测试多了一个变量：哪个 goroutine 先调用生成器。如果多个任务共用一个 Rand，即使生成器内部被锁保护，调用顺序也可能随调度改变。结果可能没有数据竞争，却仍然无法按任务稳定复现。

package randtest

import (
	"math/rand"
	"sync"
)

func valuesShared(seed int64, jobs int) []int {
	r := rand.New(rand.NewSource(seed))
	values := make([]int, jobs)
	var wg sync.WaitGroup

	for i := 0; i 

这段代码还有一个更直接的问题：rand.NewSource 返回的 Source 不保证并发安全，外层 Rand 也不能替调用方把所有并发访问变成稳定的任务级语义。不要把“没有崩溃”误认为“结果顺序可复现”。

先分清三种 API 的并发边界

当前 math/rand 文档可以按使用范围分成三类。顶层的 Intn、Float64 等函数使用包级默认源，文档明确说明它们可以被多个 goroutine 并发调用；但这只解决并发安全，不保证每个任务获得固定的那一段序列。

rand.NewSource(seed) 返回的 Source 不安全于多个 goroutine 共享。rand.New(source) 产生的 Rand 也应当由单个 goroutine 使用，或者由调用方用互斥锁包住每次调用。锁只能保护状态，不会让任务和随机数之间建立稳定映射。

因此测试设计要先回答两个问题：是否需要任务之间相互独立？失败时能否仅凭基础种子和任务编号重建输入？如果两个答案都是“是”，就应该使用任务级局部源，而不是在测试初始化中调用一次全局 rand.Seed。

为每个并发任务派生独立随机源

最小迁移方式是把任务编号纳入种子。示例中的加法只是演示稳定映射；正式项目可以使用明确的无符号混合函数或哈希，但要记录规则并避免整数溢出造成的隐含歧义。

package randtest

import (
	"math/rand"
	"sync"
)

func valuesPerJob(baseSeed int64, jobs int) []int {
	values := make([]int, jobs)
	var wg sync.WaitGroup

	for jobID := 0; jobID 

这里的“可复现”是任务级的：给定 baseSeed 和 jobID，同一个任务的输入序列可以重建；它不是承诺所有 goroutine 的完成顺序一致。测试结果应按任务编号收集，不能把 channel 接收顺序直接当作业务顺序。

从全局 rand.Seed 迁移到局部 Rand

旧代码常在测试入口写 rand.Seed(42)，然后让所有函数使用包级函数。当前文档已将顶层 Seed 标记为弃用：从 Go 1.20 起，想要固定序列应改为 rand.New(rand.NewSource(seed))；从 Go 1.24 起，默认情况下顶层 Seed 不再改变默认生成器，旧行为需要显式设置 GODEBUG=randseednop=0 才能恢复。

迁移时不要把兼容开关当成长期方案。把随机源作为依赖传给需要生成测试数据的函数，既能隔离任务，也能在失败日志里记录种子。

package randtest

import "math/rand"

type CaseInput struct {
	Seed  int64
	Value int
}

func makeInput(baseSeed int64, caseID int) CaseInput {
	seed := baseSeed + int64(caseID) // 保存这两个字段就能重建本用例。
	r := rand.New(rand.NewSource(seed))
	return CaseInput{
		Seed:  seed,
		Value: r.Intn(1000), // 业务函数只接收已经固定的输入。
	}
}

如果确实要在多个 goroutine 共享一个 Rand，应明确使用互斥锁，并把“随机数属于哪个任务”作为额外数据保存；但对测试输入生成来说，任务级随机源通常更简单，也更容易定位失败样本。

让失败样本能被重新构造

建议在失败信息中同时记录基础种子、任务编号和派生种子，而不是只打印某个随机结果。重新运行时按同一规则创建局部源，再先验证输入构造，最后进入被测逻辑。

常见追问

固定同一个 seed，为什么结果还是会变？

如果多个 goroutine 共用一个随机状态，谁先消耗下一个值由调度决定。固定 seed 只能固定序列的起点，不能固定并发调用的交错顺序。给每个任务分配独立源并按任务编号收集结果，才能缩小复现变量。

给每个 goroutine 用相同 seed 可以吗？

可以得到相同的初始序列，但通常会让不同任务产生重复输入。更稳妥的是用基础种子加任务编号派生不同 seed，并把派生规则写进失败记录。

测试代码还应该调用 rand.Seed 吗？

新代码不应把它作为局部复现方案。当前文档建议用 rand.New(rand.NewSource(seed)) 创建局部生成器；如果维护旧代码，要把 Go 版本变化和迁移计划写清楚。

并发测试的复现重点不是“所有线程共享一个固定随机序列”，而是“每个任务的输入状态可以独立重建”。区分顶层函数与局部 Rand 的并发边界，再记录基础种子、任务编号和派生种子，通常就能把偶发失败变成可追踪的回归用例。