Go math/rand/v2 和 crypto/rand 怎么按用途选择

Go 里“随机”不是一个统一需求。抽样、洗牌、模拟退避需要的是统计分布和可复现能力；登录令牌、密码重置链接、会话密钥需要的是攻击者难以预测的字节。前一类选 math/rand/v2，后一类选 crypto/rand。即使 math/rand/v2 的 ChaCha8 比旧实现更难预测，官方仍把它定位为通用伪随机包，而不是安全秘密的来源。

先按用途判断：模拟与安全令牌不是一类随机数

可以先问两个问题：结果会不会成为安全凭据？测试是否必须重放同一序列？如果答案分别是“会”和“不需要”，就用 crypto/rand；如果答案是“不会”和“需要”，就用 math/rand/v2 的独立生成器。随机退避、抽样、游戏事件、模拟数据通常属于前者的非安全场景。

这张表的“安全”指不可预测性，不是说每个随机算法都能自动解决权限、过期时间或重放问题。令牌仍要配合长度、过期和服务端校验。

math/rand/v2 的并发与复现边界

顶层的 rand.IntN、rand.Float64 等函数可以被多个 goroutine 调用。但一旦自己创建 Source 或 Rand，就要把它当作有所有权的状态对象：同一个实例只交给一个 goroutine，或者在外面加锁。需要重放测试时，本地 PCG 比依赖全局随机流更清楚。

package main

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

func main() {
	// 固定两个种子，让测试每次得到同一条本地序列。
	r := rand.New(rand.NewPCG(12, 34))
	for i := 0; i 

这个 Rand 适合测试和模拟，不要把它放进共享单例后让多个协程同时调用。若业务确实要共享一个序列，应在访问处使用互斥锁；若更看重吞吐，给每个 worker 分配独立源，并记录种子，排查时才能复现。

crypto/rand 如何生成不可预测的秘密值

生产代码生成令牌时，直接读 crypto/rand 的字节即可。下面的函数把 32 个随机字节编码成十六进制字符串；它没有固定种子，也没有把秘密打印到日志里。

package token

import (
	crand "crypto/rand"
	"encoding/hex"
)

func New() (string, error) {
	buf := make([]byte, 32)
	// 从系统安全随机源填满缓冲区，错误必须向调用方报告。
	if _, err := crand.Read(buf); err != nil {
		return "", err
	}
	return hex.EncodeToString(buf), nil
}

crypto/rand.Reader 是全局共享且支持并发使用的安全随机源。测试时不要改生产函数去接受一个“固定种子”；把生成逻辑抽成接收 io.Reader 的小函数，测试传入可控 reader，生产再传 crypto/rand.Reader，这样随机来源和测试替身的边界都显式存在。

把选择落到接口和检查清单

代码审查可以按四项快速收口：一看输出是否用于认证或授权；二看是否必须重放；三看 Rand 的实例所有权；四看测试是否通过 reader 注入而不是改全局状态。只要第一项涉及秘密，就算代码“只是生成一个短数字”，也不能因为方便而换成 math/rand/v2。

• 抽样、退避、洗牌：使用 math/rand/v2，需要复现就固定本地 PCG。
• 令牌、密钥、密码重置码：使用 crypto/rand，再单独设计过期和校验。
• 并发：顶层函数和 crypto/rand.Reader 可并发；自建状态对象要隔离或同步。

常见问题

math/rand/v2 的 ChaCha8 能不能生成登录令牌？

不要这样设计。包文档仍将它定位为通用伪随机，安全秘密使用 crypto/rand 更直接，也更容易通过代码审查。

固定种子能不能让 crypto/rand 可复现？

不能，也不应该。测试应注入一个实现 io.Reader 的可控来源，生产路径继续使用系统安全随机源。

共享一个 rand.Rand 会不会自动并发安全？

不会。自建 Source 和 Rand 要单协程使用，或由调用方用锁保护。