crypto/rand.read 更适合密钥生成，因其调用操作系统真随机源（如 /dev/urandom），输出不可预测、无周期、抗重放；而 math/rand 是伪随机，种子可预测则序列可复现，密钥生成必须用 crypto/rand。
crypto/rand.Read 为什么比 math/rand 更适合密钥生成
crypto/rand 底层调用操作系统提供的真随机源（如 Linux 的 /dev/urandom，Windows 的 BCryptGenRandom），输出不可预测、无周期、抗重放。而 math/rand 是伪随机，种子一旦暴露或可预测，整条序列就可复现——这对密钥、token、nonce 来说等于直接交出控制权。
- 密钥生成必须用
crypto/rand，math/rand再快也不行 -
crypto/rand.Read是最常用入口，它返回error而非 panic，必须显式检查 - 不要自己封装成“无错误版”，忽略
io.EOF或io.ErrUnexpectedEOF可能导致密钥截断
buf := make([]byte, 32)
if _, err := rand.Read(buf); err != nil {
log.Fatal("failed to read secure random: ", err) // 别只 print，得处理
}生成 AES 密钥或 RSA 私钥时的字节长度陷阱
AES-256 要 32 字节，不是 256 个字符；RSA-2048 私钥不是“生成 2048 字节”，而是由 crypto/rsa.GenerateKey 内部调用 crypto/rand 完成——你只需传入 *rand.Reader。
- 直接调
rand.Read生成对称密钥时，务必按算法要求分配精确字节数：16（AES-128）、32（AES-256） - 错误写法：
rand.Read(make([]byte, 256))→ 得到 256 字节垃圾，AES 会 panic：“invalid key size” - 生成私钥不要自己拼
[]byte，用标准库函数：rsa.GenerateKey(rand.Reader, 2048)，它内部已做熵校验和参数约束
在容器或无特权环境里 crypto/rand.Read 失败的常见原因
Docker 默认禁止访问 /dev/random，但允许 /dev/urandom；然而某些精简镜像（如 scratch 或 distroless）可能没挂载该设备节点，或 seccomp 策略拦截了 getrandom(2) 系统调用。
- 错误现象：
read /dev/urandom: operation not permitted或卡住（等待阻塞型熵池） - 检查方式：容器内执行
strace -e trace=getrandom,openat go run main.go 2>&1 | grep -i fail - 解决路径优先级：
- 确保基础镜像包含
/dev/urandom（Alpine ≥3.16、Debian ≥11 默认支持） - 避免使用
--cap-drop=ALL或自定义 seccomp profile，除非明确放行getrandom - 不要 fallback 到
math/rand，宁可启动失败，也别降级安全
- 确保基础镜像包含
为什么不能用 crypto/rand 生成 session ID 或短 token
能用，但没必要——crypto/rand 是重量级系统调用，频繁小量读取（比如每次 HTTP 请求生成 16 字节）会成为性能瓶颈，尤其在高并发下。更合适的是用 crypto/rand 初始化一个 math/rand 实例，再用它派生。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：一次性读 32 字节作为 seed，构造独立的
rand.New实例 - 错误做法：每个请求都调
rand.Read(buf) - 注意：这个派生的
math/rand只用于非密钥场景（如 session ID、临时文件名），绝不可用于加密上下文
seedBuf := make([]byte, 8)
rand.Read(seedBuf) // 一次系统调用
src := rand.NewSource(int64(binary.LittleEndian.Uint64(seedBuf)))
r := rand.New(src)
id := fmt.Sprintf("%x", r.Uint64()) // 快，且足够防碰撞真随机不是万能胶水，它贵在不可预测，也贵在系统开销。什么时候该咬牙走系统调用，什么时候可以安全缓存/派生，边界就在“是否会被攻击者观测或影响”这一条线上。
