crypto/rand.Read 更安全因其使用操作系统真随机源（如 /dev/urandom），而 math/rand 是可预测的伪随机；适用于密钥、token 等敏感场景，禁用于性能敏感非安全场景；需检查错误、避免手动拼接编码、勿替换默认 Reader。
crypto/rand.Read 为什么比 math/rand 更安全
因为 math/rand 是伪随机，种子固定时输出完全可预测；crypto/rand 读取操作系统提供的真随机源（如 Linux 的 /dev/urandom），适合生成密钥、token、salt 等敏感数据。
常见错误现象：math/rand.Intn(100) 被误用于生成 API token，结果被暴力穷举破解。
- 使用场景：JWT secret、AES key、密码重置码、session ID
- 不适用场景：游戏抽卡、排序打乱（性能敏感且无需密码学安全）
-
crypto/rand在容器或 chroot 环境中可能阻塞（旧内核或配置异常时读/dev/random），但现代 Go 默认用/dev/urandom，基本无延迟
如何正确生成固定长度的随机字节或字符串
别自己拼接 base64 或 hex——容易引入偏差或截断 bug。直接用 crypto/rand 填充字节切片，再转编码。
示例：生成 32 字节随机 token 并转成 hex
立即学习“go语言免费学习笔记（深入）”；
buf := make([]byte, 32)
_, err := rand.Read(buf)
if err != nil {
// 处理 err，比如日志 + 返回
}
token := hex.EncodeToString(buf)
- 必须检查
err！虽然极少发生，但设备无随机源时会返回io.EOF或io.ErrUnexpectedEOF - 避免用
rand.Int()或rand.Int31()——它们不保证密码学安全，且接口易误用 - 不要重复调用
rand.Read多次填小 buffer，一次大 buffer 更高效、更少系统调用
crypto/rand 在 Windows 和 macOS 上的行为差异
行为一致：Go 运行时自动适配各平台的安全随机 API（Windows 用 BCryptGenRandom，macOS 用 SecRandomCopyBytes），开发者无需条件编译。
但要注意：
- 在某些极老版本 Windows（如 Win7 SP0）上，若 CNG 未正确安装，
rand.Read可能返回error，建议 Go 版本 ≥ 1.16（修复了多个平台兼容性边界 case） - 交叉编译时不会出错，但运行时依赖目标系统能力——测试必须在真实目标 OS 上跑，不能只信 CI 的 Linux 环境
- 容器环境（尤其是 distroless 镜像）默认包含
/dev/urandom，无需额外挂载，但精简镜像若删了devtmpfs支持，就会失败
和第三方库（如 golang.org/x/crypto/chacha20poly1305）混用时的常见坑
这些库内部也依赖 crypto/rand，但如果你手动传入自定义 io.Reader（比如包装了 rand.Reader 的限速器），可能破坏其安全假设。
- 除非明确文档允许，否则永远用默认的
crypto/rand.Reader，不要替换为bytes.NewReader或 mock reader 做单元测试 - 测试中需要可控随机？用
gobuffalo/packr/v2类工具不适用；应改用函数注入，例如把func() ([]byte, error)作为参数传入，测试时用固定 seed 的math/rand实现 - 注意
crypto/rand不是线程安全的“实例”，它本身就是包级全局变量，多 goroutine 并发调用Read完全没问题
真正麻烦的是：你写了 100 行逻辑确保随机数够长、编码无偏差、错误被处理，结果上线后发现某处漏了 if err != nil，而那个 err 恰好只在硬件 RNG 故障时才出现——这种问题线上几乎无法复现，只能靠静态检查和防御性 panic 日志兜底。
