必须用crypto/rand生成UUIDv4，因math/rand可预测、种子易冲突、不满足CSPRNG要求；crypto/rand调用系统熵源（如/dev/urandom），需位操作设版本位（0x40）和变体位（0x80）以符合RFC 4122。
crypto/rand 是 Go 中唯一推荐用于密码学安全场景的随机数源，math/rand 绝对不能用于生成密钥、token 或 UUIDv4 —— 它可预测，且默认种子基于时间，极易被爆破。
为什么不能用 math/rand 生成 UUID？
常见错误是直接调用 math/rand.Int63() 或用 rand.New(rand.NewSource(time.Now().UnixNano())) 构造随机数器来填充 UUID 字节。这会导致：
- 同一毫秒内启动的多个实例可能产生完全相同的 UUID（种子冲突）
- 进程运行时若未显式重置种子，
math/rand默认使用固定种子，所有输出可复现 - 即使手动设了纳秒级种子，仍不满足 CSPRNG（密码学安全伪随机数生成器）要求，无法通过 NIST SP 800-90A 等测试
UUIDv4 规范明确要求“四字节随机数必须来自高质量随机源”，crypto/rand 是 Go 标准库中唯一满足该条件的实现。
用 crypto/rand 生成 16 字节安全随机数
这是构建 UUIDv4 的基础操作。核心是调用 rand.Read() 填充一个预分配的 []byte，它会阻塞直到操作系统提供足够熵（Linux 下读 /dev/urandom，Windows 调用 BCryptGenRandom）。
正确写法：
buf := make([]byte, 16)
if _, err := rand.Read(buf); err != nil {
log.Fatal(err) // 不要忽略 err！设备无熵或权限不足时会失败
}
注意点：
-
rand.Read()返回实际读取字节数，必须检查是否等于预期长度（尤其是传入小缓冲区时） - 不要用
io.ReadFull(rand.Reader, buf)—— 它在短读时返回io.ErrUnexpectedEOF，而rand.Read()更直白 - 避免反复创建新切片：复用
buf可减少 GC 压力，尤其高频生成场景
生成标准 UUIDv4 的完整实现
UUIDv4 要求第 13 位字节高 4 位为 0100（即 0x40–0x4f），第 17 位字节高 2 位为 10（即 0x80–0xbf）。只需对原始随机字节做位掩码：
func newUUID() [16]byte {
var uuid [16]byte
if _, err := rand.Read(uuid[:]); err != nil {
panic(err) // 或按需处理
}
uuid[6] = (uuid[6] & 0x0f) | 0x40 // 版本号设为 4
uuid[8] = (uuid[8] & 0x3f) | 0x80 // 变体设为 RFC 4122
return uuid
}
关键细节：
- 直接操作
[16]byte底层数组比用[]byte更省内存且零拷贝 - 第 6 字节（索引从 0 开始）对应 UUID 字符串的第 13 个字符位置（如
xxxxxxxx-xxxx-<strong>4</strong>xxx-xxxx-xxxxxxxxxxxx） - 第 8 字节对应变体字段，必须是
0b10xxxxxx，否则解析器可能拒绝（如某些 PostgreSQL 驱动）
性能与并发注意事项
crypto/rand 在 Linux 上本质是系统调用，单次 Read() 16 字节开销极小（微秒级），但高频调用（如每毫秒上千次）可能成为瓶颈。
优化建议：
- 批量生成：一次读取 1KB 随机字节，从中切片复用，适合 token 池或预生成场景
- 无需加锁：标准库的
rand.Reader是并发安全的，多 goroutine 直接调用rand.Read()即可 - 容器环境要注意：Docker 默认不挂载
/dev/urandom，但现代内核已支持 getrandom() 系统调用回退，一般无需额外配置；Kubernetes Pod 若启用了securityContext.readOnlyRootFilesystem: true，只要内核 ≥3.17 就不受影响
真正容易被忽略的是错误处理——rand.Read() 在低熵环境（如刚启动的嵌入式设备）或 chroot 沙箱中可能返回 io.ErrUnexpectedEOF 或其他系统错误，生产代码里不能只写 _ , _ := rand.Read(...)。
