crypto/rand.Read 是 Go 中生成加密安全随机字节的首选方式，直接填充已分配切片，底层调用系统熵源，线程安全且无需手动管理；误用 math/rand、未检查错误、重复调用或不当转整数均会导致安全隐患。
crypto/rand.Read 生成字节序列最可靠
用 crypto/rand.Read 直接填充字节数组，是 Go 里生成加密安全随机值的首选方式。它底层调用操作系统提供的熵源（如 Linux 的 /dev/urandom），不依赖种子、不缓存、不可预测。
常见错误是误用 math/rand 替代——它只是伪随机，Seed 一旦暴露或重复，整个序列可被还原，完全不适用于 token、密钥、salt 等场景。
- 必须传入已分配长度的切片，例如
buf := make([]byte, 32)；传 nil 或未初始化切片会 panic - 返回
error需显式检查：系统熵池枯竭极罕见，但容器环境或嵌入式设备可能触发io.ErrUnexpectedEOF - 不要对同一
[]byte多次调用Read期望“更随机”——单次调用已满足密码学强度
从 crypto/rand 得到整数要自己转换
crypto/rand 不提供直接生成 int 或 int64 的函数，因为整数范围和字节边界不天然对齐。强行用 binary.Read 或 unsafe 转换容易引入偏移（bias）——比如想取 [0, 100) 却因截断导致 0 出现概率略高。
正确做法是：先读足够字节，再用拒绝采样（rejection sampling）确保均匀分布。
立即学习“go语言免费学习笔记（深入）”；
- 生成 [0, n) 区间整数：用
rand.Intn(n)是错的——它基于math/rand；应改用rand.New(rand.NewSource(...))？不行，这又回到伪随机 - 推荐组合：
crypto/rand+math/big.Int，例如rand.Int(rand.Reader, big.NewInt(100))，它内部已实现无偏拒绝采样 - 若追求性能且 n 是 2 的幂（如 256、65536），可用位运算截取：读 8 字节 →
binary.LittleEndian.Uint64(buf) & (n-1)，但仅限 n 为 2^k
crypto/rand.Reader 是全局共享的，别封装成私有实例
crypto/rand.Reader 是包级变量，类型为 io.Reader，线程安全，内部已做并发控制。有人为“避免全局状态”把它包装进 struct 并在初始化时复制，这是多余且有害的。
典型错误写法：type SecureRand struct { r io.Reader }; func New() *SecureRand { return &SecureRand{r: rand.Reader} }——不仅没增益，还可能误导使用者以为可替换底层实现。
- 直接用
rand.Reader，无需 import 别名或重命名 - 测试时想 mock？
rand.Reader本身是接口，可传入自定义io.Reader（如预设字节流），但生产环境绝不能替换为bytes.NewReader或strings.NewReader - 在 init 函数里调用
rand.Reader.Read没问题，它不会阻塞；但别在 init 里反复读几 MB——没必要
Windows 下 crypto/rand.Read 可能慢，但通常不是瓶颈
Windows 用 BCryptGenRandom 实现 crypto/rand，首次调用有少量初始化开销（加载 BCrypt.dll、获取句柄），后续调用很快。极少情况下（如 Server Core 环境缺少 CNG 支持），会 fallback 到较慢路径并返回 error。
这不是代码 bug，而是平台限制。如果你在 Windows 容器中看到 crypto/rand.Read 偶发超时，优先检查是否启用了 Credential Guard 或 Device Guard——它们会拦截部分加密 API。
- 不用主动做平台判断或写 if runtime.GOOS == "windows" 分支
- 如果真遇到性能敏感场景（如每秒生成上万 token），可预先批量读取（例如一次读 4KB，缓存后分片使用），但需自行管理并发访问
- 绝大多数 Web 服务、CLI 工具、配置生成器，直接调用
Read完全够用，别过早优化
真正容易被忽略的是：加密随机数 ≠ “看起来随机”。哪怕 crypto/rand 正确使用，如果后续把生成的 bytes 直接 base64 编码后当 JWT ID 用，却没校验长度或去重，照样会因业务逻辑出问题。安全随机只是必要条件，不是充分条件。
