Go math/rand/v2 ChaCha8 种子相同但序列不同怎么办

先给结论：Go math/rand/v2 的 ChaCha8 在两边使用完全相同的 [32]byte 种子、都从新实例开始，并且按相同方法顺序消费时，原始 Uint64 序列应当一致。序列不同，通常不是“同一个种子失效”，而是输入字节、实例状态或消费方式有一处没有对齐。

官方地址：https://pkg.go.dev/math/rand/v2

本文把排查顺序固定为：先看种子，再看实例是否已经被消费，然后看 Read 和 Uint64 是否交错，最后才看 Rand 包装和并发。下面的代码是原创示例，输出只用于说明比较方式，不代表本环境已执行。

先确认 ChaCha8 的初始化语义

在 math/rand/v2 中，ChaCha8 的种子类型是固定长度的 [32]byte，不是任意长度的字符串。NewChaCha8(seed) 用这份种子创建新源，Seed(seed) 会把已有源重置为与新建实例相同的初始状态。因而排查时要比较完整的 32 个字节，而不是只打印一部分或比较字符串的展示形式。

先用两个互不共享的实例比较连续 Uint64。这相当于把“输入是否相同”和“状态是否被前面的代码消耗”从业务逻辑里隔离出来。

package main

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

// sequence 只从新建的 ChaCha8 读取原始 Uint64，避免混入其他消费入口。
func sequence(seed [32]byte, count int) []uint64 {
    source := rand.NewChaCha8(seed)
    values := make([]uint64, count)
    for i := range values {
        // Uint64 是本例唯一的消费方法，便于比较原始源序列。
        values[i] = source.Uint64()
    }
    return values
}

func main() {
    var seed [32]byte
    copy(seed[:], []byte("replay-seed-v1"))

    left := sequence(seed, 3)
    right := sequence(seed, 3)
    fmt.Println(left)
    fmt.Println(right)
}

如果这类比较一致，说明 ChaCha8 本身的初始化路径没有问题。若项目代码仍然不同，下一步不要更换算法，先确认种子是否在序列化、配置读取或哈希转换时被改过；特别是把字符串填入数组时，剩余字节会保持零值，截断和补零策略必须两边一致。

实例已经消费过，重新使用同一变量也不会回到开头

随机源保存的是可变内部状态。同一个 ChaCha8 先被调用几次，再拿去与另一个刚初始化的实例比较，种子虽然文字上相同，比较的却不是同一个状态位置。常见的误判是：测试函数复用了全局源，或者初始化函数之外还有日志采样、ID 生成等代码提前取走了随机值。

需要从同一种子重新开始时，使用新的实例，或者显式调用 Seed 重置；不要依赖“上一次调用正好消耗了多少”。如果把源交给 rand.New，还要记住包装器和底层 ChaCha8 共享消费状态。

package replay

import "math/rand/v2"

// NewRand 为每次回放返回独立的 Rand，调用方不会误用上一轮的内部状态。
func NewRand(seed [32]byte) *rand.Rand {
    source := rand.NewChaCha8(seed)
    // Rand 只负责把 Source 转成 IntN、Float64 等派生接口。
    return rand.New(source)
}

// ResetForReplay 显式回到同一种子的起点；调用方应丢弃旧的派生结果。
func ResetForReplay(source *rand.ChaCha8, seed [32]byte) {
    source.Seed(seed)
}

这里的“相同序列”应明确指相同消费方式下的原始值。Rand.IntN、Float64 等派生方法可能按各自的取样逻辑消费底层源，不能把“调用了三次派生方法”机械等同为“底层只前进三步”。测试应比较业务真正需要的结果，并固定调用顺序。

不要混用 Read 与 Uint64

ChaCha8 同时提供 Read 和 Uint64。官方文档明确说明：如果二者交错调用，返回位的顺序没有定义，Read 还可能返回在上一次 Uint64 之前生成的位。因此“同一种子但一边先 Read、另一边先 Uint64”不构成可复现比较条件。

工程上有两个清晰选择：需要原始数字序列时，只通过 Uint64 取值；需要字节流时，只通过 Read 取字节。不要为了省一个实例，在同一个源上交替承担这两种协议。

package replay

import "math/rand/v2"

// BytesForReplay 规定该源只作为字节流使用，不与 Uint64 交错。
func BytesForReplay(seed [32]byte, size int) []byte {
    source := rand.NewChaCha8(seed)
    output := make([]byte, size)
    // Read 会填满 output；调用方不再用同一 source 读取 Uint64。
    _, _ = source.Read(output)
    return output
}

// NumbersForReplay 规定该源只作为 Uint64 序列使用。
func NumbersForReplay(seed [32]byte, size int) []uint64 {
    source := rand.NewChaCha8(seed)
    output := make([]uint64, size)
    for i := range output {
        output[i] = source.Uint64()
    }
    return output
}

图中把 Read、Uint64、ChaCha8 和 rand.New 画成同一消费边界内的不同入口，是为了提醒读者先确定协议，不表示某条箭头是已经运行过的时间顺序。

把并发和安全用途从复现问题中分开

Source 不适合在多个 goroutine 中无同步共享。并发调用会改变谁先消费状态，因而即使种子相同，业务观察到的序列也可能与单线程回放不同。若每个 goroutine 都要复现，给它分配独立的种子和独立的 ChaCha8；若必须共享，就在调用边界做同步，并接受调用顺序成为协议的一部分。

另一个边界是安全性。ChaCha8 适合通用伪随机、模拟和回放，但 math/rand/v2 文档仍提醒：其输出无论怎样播种都可能被预测。生成令牌、密钥或其他安全敏感随机数时，应使用 crypto/rand，不能因为名称里有 ChaCha8 就把它当成安全随机接口。

相关问题

调用 Seed 后一定和新建 ChaCha8 一样吗？

就 ChaCha8 的初始状态而言，官方定义是重置为与 NewChaCha8(seed) 相同；但如果重置后两边的调用方式不同，后续派生结果仍然不能直接比较。

相同种子能保证跨版本所有结果都不变吗？

不要把应用协议建立在未声明的实现细节上。对当前 Go 文档承诺的接口和固定调用路径做回放测试；若要长期保存跨版本的结果，还应把工具链和调用协议一并固定。

ChaCha8 可复现就能替代 crypto/rand 吗？

不能。可复现方便调试，安全随机要求不可预测，两者目标不同。安全敏感场景使用 crypto/rand。

参考资料：

• https://pkg.go.dev/math/rand/v2@go1.27.3#ChaCha8
• https://go.dev/src/math/rand/v2/chacha8.go