math/rand 不适合生成密码学安全随机数，因其是依赖种子的伪随机数生成器，可被预测重现，且不读取系统熵源；应改用 crypto/rand，它基于操作系统熵池（如 /dev/urandom），提供不可预测、抗重放的安全随机数。
为什么 math/rand 不适合生成密码学安全随机数
math/rand 是伪随机数生成器（PRNG），依赖种子初始化，一旦种子被预测或复用，整个序列可被重现。它不读取操作系统熵源，无法满足密钥、token、salt 等场景的安全性要求。常见错误是用 rand.Intn(100) 生成 session ID 或加密盐值——这会导致碰撞风险陡增，甚至被批量预测。
真正需要“不可预测”“抗重放”的地方，必须切换到密码学安全的随机源。
用 crypto/rand 读取操作系统熵池
crypto/rand 是 Go 标准库中唯一推荐的密码学安全随机数接口，底层调用 Linux 的 /dev/urandom、Windows 的 BCryptGenRandom 等系统级熵源。它不阻塞，也不需要手动 seed，开箱即用。
常用操作包括：
- 生成固定长度字节切片：
rand.Read(buf)，返回n, err，务必检查err（仅在系统熵枯竭等极端情况下失败） - 生成 uint64：
rand.Uint64()（Go 1.22+），比手动拼接更简洁安全 - 生成指定范围整数（需自行实现）：不能直接用
Intn，要配合模削减（rejection sampling）防止偏差
示例：生成 32 字节随机 token
buf := make([]byte, 32)
_, err := rand.Read(buf)
if err != nil {
log.Fatal(err) // 不应忽略
}
token := hex.EncodeToString(buf)
生成随机字符串时别直接拼 ASCII 字符
直接用 rand.Intn(26) + 'a' 拼字母，看似简单，但若底层用 math/rand 就完全失效；即使换 crypto/rand，手动映射也易出错（比如没处理模偏差、字符集重复、大小写混淆）。
更稳妥的做法是：
- 先用
crypto/rand.Read()生成字节流 - 用查表法映射到目标字符集（如 URL-safe Base64 或自定义字母表）
- 避免使用
fmt.Sprintf或字符串拼接做转换，防止隐式类型截断
示例：生成 16 位 URL-safe 随机字符串
b := make([]byte, 16) _, _ = rand.Read(b) s := base64.URLEncoding.EncodeToString(b)[:16] // 注意截断不改变安全性
注意 crypto/rand 在容器或无熵环境中的行为
绝大多数现代 Linux 容器（Docker/Podman）默认挂载 /dev/urandom，无需额外配置。但极简镜像（如 scratch 或某些 initramfs）可能缺失设备节点，此时 rand.Read 会返回 errors.ErrNoEntropy（Go 1.22 前）或直接 panic（1.22+ 改为返回 error）。这不是 bug，而是安全机制。
排查方法：
- 运行
ls -l /dev/urandom确认设备存在且可读 - 在 CI 或 serverless 环境中，避免用最小化基础镜像启动关键服务
- 不要尝试用
time.Now().UnixNano()或 PID 补充 entropy——这只会降低安全性
真正难的不是调用哪个函数，而是始终分清「随机」和「密码学安全随机」的边界。一次误用 math/rand 生成 API key，就可能让整个服务暴露。
