math/rand/v2 Shuffle 打乱切片并隔离全局状态的方法

Go 使用 math/rand/v2 打乱切片并隔离随机状态时，可以为任务创建 rand.New(rand.NewPCG(seed1, seed2))，再调用它的 Shuffle 方法。Shuffle 会通过交换回调原地修改数据；如果需要保留输入顺序，应先复制切片，再让回调只交换副本。局部随机源与切片副本解决的是两个不同的共享问题。

目标和边界：隔离的是哪两种状态

在设计任务列表的随机顺序时，我会先问两个问题：其他模块的随机调用能否影响本任务，以及调用结束后原列表是否必须保持原样。只把包级 Shuffle 换成局部方法，可以回答第一个问题，却不会自动保护原切片。

本文采用“每次任务新建随机源、复制输入、只返回副本”的封装，适合模拟、顺序扰动和需要重现条件的非安全任务。math/rand/v2 从 Go 1.22 起提供。这里不使用旧 math/rand 的全局 Seed，也不把固定种子的伪随机结果当成安全随机材料。

全流程总览：把随机状态与切片存储分开

种子对用于初始化 PCG，Rand 包装这个源，Shuffle 从该对象取得随机值并调用交换回调。回调中的 i、j 是元素下标，真正的数据交换由调用者实现。只要回调捕获的是副本，原始切片的元素位置就不会被这次交换改变。

我更愿意把这个依赖关系写在封装里，而不是要求每个调用点记住“先复制，别用包级对象”。封装同时收进输入和种子，降低遗漏某一步的可能性；代价是每次调用都复制元素槽位，并创建新的随机对象，是否值得仍取决于任务需求。

阶段拆解：复制输入、建立源、完成交换

下面是完整单文件示例。第一次和第二次调用都从同一份原始输入开始，各自创建相同种子的源；中间加入一次包级随机调用，突出两类状态没有共用同一个源。代码用于说明行为，没有给出伪造的执行输出或性能数字。

package main

import (
    "fmt"
    rand "math/rand/v2"
    "slices"
)

func shuffledCopy[T any](input []T, seed1, seed2 uint64) []T {
    // 复制元素槽位，交换副本时不修改输入的底层数组。
    out := slices.Clone(input)
    // 每次调用拥有自己的源，外部随机调用不会推进这个状态。
    r := rand.New(rand.NewPCG(seed1, seed2))
    r.Shuffle(len(out), func(i, j int) {
        out[i], out[j] = out[j], out[i]
    })
    return out
}

func main() {
    original := []string{"job-a", "job-b", "job-c", "job-d", "job-e"}
    first := shuffledCopy(original, 17, 29)

    // 消耗包级随机值，说明它与 helper 内的局部源没有共享状态。
    _ = rand.Uint64()
    second := shuffledCopy(original, 17, 29)

    fmt.Println("输入:", original)
    fmt.Println("第一次:", first)
    fmt.Println("第二次:", second)
    // 在相同实现、输入和种子条件下，两个新源对应相同调用序列。
    fmt.Println("两次一致:", slices.Equal(first, second))
}

按这个封装的逻辑，original 的五个元素保持原顺序；相同实现、相同初始输入和相同种子对得到相同的打乱结果。本文不列出某个精确排列，避免把特定实现下的一组顺序当成 API 保证。随机排列也可能恰好等于原顺序，不应把“看起来没变”直接判为函数失效。

slices.Clone 是浅复制：当元素是字符串时，本例只需要独立的元素槽位；如果元素是指针、切片或包含映射的结构体，元素指向的对象仍可能共享。Shuffle 不会修改那些对象的内容，但后续修改会不会互相影响，需要按数据模型另外处理。

nil 和空切片的长度都是 0，传给 Shuffle 不需要执行元素交换；单元素切片也没有需要改变的排列。使用 len(out) 作为 n，比让调用方额外传一个可能不匹配的长度更清楚；负 n 会触发 panic，不应作为普通业务错误路径使用。

推荐流程：按任务分配对象和复现资料

先固定任务输入，再记录种子对和工具链信息。输入如果来自 map 遍历，先定义稳定的排序规则，再交给打乱函数；否则种子一样，起始顺序不同，结果自然也可能不同。随机结果取决于输入、算法实现和随机调用序列，种子只是其中一项。

需要每次按同一条件重现时，每次新建源并传入同样的种子对。需要一个持续推进的模拟序列时，则把同一个 Rand 交给单个任务对象顺序使用。后一种方式第二次 Shuffle 会继续消耗状态，不能期待它自动回到第一次的结果。

跨版本长期保存某个确定排列时，我会直接保存排列结果或索引排列，并记录生成条件，不只保存种子。对于同一程序中的重现，也要避免在 Shuffle 前插入额外的局部 r.Uint64 调用，因为那会改变后续状态消费的位置。

并行任务可以各自创建源和各自的切片副本，避免抢用共享状态。不同种子对并不意味着一定得到不同排列，特别是列表很短时；如果业务需要唯一顺序或去重，必须另外定义规则。

常见误区：并发安全不等于结果稳定

math/rand/v2 的包级函数支持并发调用，但这不保证对同一切片并发执行交换是安全的。随机函数内部安全与调用者捕获的数组是否共享，是两个层面。多个 goroutine 同时交换同一底层数组，仍然需要同步或独立副本。

自己创建的 Source 和 Rand 应一次由一个 goroutine 使用；共享时需要同步。即使用锁保护一个随机对象，调度顺序也可能决定哪个任务先消耗随机值，锁只能解决并发访问，不能自动让每个任务取得固定的那一段随机序列。

不要用带随机返回值的排序比较函数来代替 Shuffle。排序比较需要稳定、一致的次序关系，随机比较并没有表达这一约束。也不要把原切片重新赋值给一个局部变量就当作复制：那通常只是复制切片描述符，底层数组仍然共享。

最后，固定种子便于重现，不提供不可预测性。对于令牌、密钥等安全用途，应使用适合安全随机的接口；本文只处理切片排列和非安全任务的状态归属，不把种子管理扩大成安全设计方案。

速查表与相关问题

为什么相同种子得到的列表不一样？先检查输入是否已经被原地改过，源是否被复用，以及 Shuffle 前是否还有其他局部随机调用。不要只比较种子而忽略调用历史。

包级随机调用会推进 helper 的 PCG 吗？不会。本例每次 helper 都创建自己的 PCG；如果改成多个对象包装同一个源，那些对象就不再拥有独立状态。

打乱后有相邻重复元素是否说明算法有问题？不说明。Shuffle 重新排列已有元素，不负责去重；输入的重复值仍然存在，某些位置也可以保持不变。

官方资料：https://pkg.go.dev/math/rand/v2#Rand.Shuffle、https://pkg.go.dev/math/rand/v2#NewPCG、https://go.dev/doc/go1.22。