Go math/rand/v2 的 ChaCha8.Read 怎么复用随机流：种子恢复与并发边界

测试里有一段“生成固定字节串”的代码，换成 math/rand/v2.ChaCha8.Read 后，单独调用时结果稳定，一旦在中间插入一次 Uint64，后面的字节却对不上了。问题不在种子失效，而在同一个 ChaCha8 流被两种读取方式共同推进。

要复现一段可控的随机字节流，可以用同一个 [32]byte 种子分别创建独立的 ChaCha8，让每个实例只负责一种读取协议；需要重放时调用 Seed 重置状态，不要把它当作密码学密钥生成器。

测试现场：同一个种子为什么出现两条序列

先把变量压到最少：一个 32 字节种子、一个 ChaCha8 实例、两次读取。下面的程序只观察确定性，不把输出当作安全随机数。

package main

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

func main() {
    var seed [32]byte
    for i := range seed {
        seed[i] = byte(i)
    }

    c := rand.NewChaCha8(seed)
    buf := make([]byte, 8)
    n, err := c.Read(buf)
    fmt.Printf("n=%d err=%v bytes=%x\n", n, err, buf)
}

在 Go 1.23 及更新版本的文档中，ChaCha8.Read 是后来加入的方法；它会把 buf 填满，正常返回 8, nil。而 math/rand/v2 的全局函数并不承诺固定输出序列，回放测试应使用自己创建的实例。

动手验证：Read 和 Uint64 共同推进 ChaCha8

排查时最容易漏掉的是“谁读过这个源”。下面让 seqA 只调用 Read，让 seqB 在两次 Read 中间调用一次 Uint64。两者使用相同的 seed，但调用协议不同。

var seed [32]byte
for i := range seed {
    seed[i] = byte(i)
}

seqA := rand.NewChaCha8(seed)
firstA := make([]byte, 8)
secondA := make([]byte, 8)
_, _ = seqA.Read(firstA)
_, _ = seqA.Read(secondA)

seqB := rand.NewChaCha8(seed)
firstB := make([]byte, 8)
secondB := make([]byte, 8)
_, _ = seqB.Read(firstB)
middle := seqB.Uint64()
_, _ = seqB.Read(secondB)

fmt.Printf("A=%x %x\n", firstA, secondA)
fmt.Printf("B=%x %d %x\n", firstB, middle, secondB)

firstA 和 firstB 可以相同，因为它们都从新实例开始；差异出现在第二段。官方文档明确提醒：如果 Read 与 Uint64 交错，返回位的顺序未定义，Read 甚至可能取到上一次 Uint64 之前生成的位。这里不要拿“每次 8 字节”去推算内部块边界。

定位根因：种子相同不等于调用历史相同

NewChaCha8(seed) 只决定初始状态。实例随后保存自己的流位置；Read、Uint64 和其他读取操作都会改变这个位置。因此以下三件事必须同时一致，结果才有资格比较：

• 使用相同的 32 字节 seed。
• 从同一个初始状态开始，而不是复用已经被读取过的实例。
• 按相同顺序调用相同方法，并使用相同的切片长度。

如果测试只想验证“输入种子能否得到固定样本”，最稳妥的方式是每个测试用例重新调用 NewChaCha8。如果对象需要长期复用，可以在进入一段可重放流程前调用 Seed(seed)，它会把实例重置为与 NewChaCha8(seed) 相同的初始行为。

修复方案：把随机源和读取协议绑在一起

回放测试使用局部实例

不要把一个包级 ChaCha8 同时交给测试数据生成、抽样和字节编码逻辑。让每个职责持有自己的实例，即使未来某段逻辑增加一次 Uint64，也不会悄悄改变另一段的样本。

func sample(seed [32]byte, size int) []byte {
    source := rand.NewChaCha8(seed)
    out := make([]byte, size)
    _, _ = source.Read(out)
    return out
}

并发任务不要共享可变读取状态

ChaCha8 实例包含流状态，文章中的并发边界应按“每个 goroutine 一个实例”设计：主 goroutine 分配不同种子，任务内部只调用自己的 Read 或 Uint64。这样既不依赖调用时序，也不用用锁把随机流重新串成一个难以回放的全局序列。

复查结果：可重放，但不能越权替代 crypto/rand

修复后分别运行两次 sample(seed, 16)，只要种子、长度和调用协议不变，输出就能逐字节比较。若中间插入新的读取调用，应把它视为测试协议变化，更新固定样本或重新拆分随机源。

ChaCha8 的定位是可复现的伪随机源，不是秘密材料生成接口。登录令牌、密码重置链接、验证码和密钥材料都应使用 crypto/rand；不要因为 ChaCha8 的名字包含“cryptographically strong”就跳过安全随机 API 的边界判断。

相关问题

ChaCha8.Read 会返回短读吗？

文档定义它会读取正好 len(p) 个字节，并返回切片长度和空错误；调用方仍应保留错误检查习惯。

能不能用 Seed 恢复上一次任意位置？

不能。Seed 是回到给定种子的初始状态，不是保存和恢复流中间检查点。

ChaCha8 能不能生成密码重置令牌？

不建议。需要不可预测秘密时使用 crypto/rand，把 ChaCha8 留给模拟、测试数据和可重放的非安全随机场景。

小结

这次序列分叉的证据很具体：seqA 和 seqB 共享种子，却采用了不同的读取历史。把源实例限制在一个明确协议内，回放前重新创建或调用 Seed，再为并发任务分配独立源，问题就从“随机数不稳定”变成了可检查的状态管理。