Golang安全随机数生成技巧分享

在Go中生成真正安全的随机数绝非易事，本文直击要害：crypto/rand.Read是唯一可信的密码学安全随机字节来源，必须正确分配切片、严格检查错误、杜绝模偏差，并通过rand.Int或拒绝采样生成均匀整数；严禁使用math/rand或任何错误包装、模拟或缓冲rand.Reader的行为——哪怕一次忽略error或一个%运算符，都可能让API密钥、会话令牌或JWT沦为可预测的“裸奔”目标。

crypto/rand.Read 是生成安全随机字节的唯一正路

别碰 math/rand，它和“安全”两个字毫无关系——种子一固定，整个序列就可复现，API key、session id、密码重置令牌用它等于裸奔。

crypto/rand.Read 才是 Go 里真正从操作系统熵池（比如 Linux 的 /dev/urandom）读取不可预测字节的函数。它不生成 int，不拼字符串，只干一件事：把随机字节塞进你给的切片里。

• 必须传入已分配长度的切片，例如 buf := make([]byte, 32)；传 nil 或未初始化切片会 panic
• 必须检查返回的 error：虽然罕见，但系统熵暂时不足时可能返回 io.ErrUnexpectedEOF，忽略它可能让 token 只填了一半
• 别对同一 []byte 多次调用 Read 以为“更随机”——单次已满足密码学强度，重复调用没意义，还可能掩盖错误

生成安全整数不能用模运算，要用 rand.Int 或拒绝采样

想生成 [0, 100) 的随机整数？别写 int(rand.Read(...)) % 100 ——这是经典模偏差（modulo bias），因为 256 不整除 100，余数 0~99 分布不均，小数字概率略高。

正确做法只有两种：

• 用 rand.Int(rand.Reader, big.NewInt(100))：它内部已实现拒绝采样，保证均匀，返回 *big.Int，小范围直接转 .Int64() 即可（只要 max ≤ math.MaxInt64）
• 自己手写拒绝采样：比如字符集长 62，每次读 1 字节，只接受 0–61，超出就丢弃重读；平均 1.1 次就能拿到一个有效值，性能无感
• 若 n 是 2 的幂（如 256、65536），可用位运算截取：binary.LittleEndian.Uint64(buf) & (n-1)，但仅限此场景，别滥用

生成随机字符串别拼字母表，先填字节再编码

常见错误是循环调用 rand.Intn(len(alphabet)) 拼字符串——这要么用了 math/rand，要么用了 crypto/rand 但没处理模偏差，源头就不安全。

正确路径永远是：生成原始字节 → 映射到目标字符集（用拒绝采样）→ 编码输出。

• 避免 base64.StdEncoding：含 + 和 /，URL 或 HTTP header 里会被代理误解析；= 填充符也可能被截断
• 优先用 base64.RawURLEncoding：无符号、无填充，适合 token、文件名、JWT
• 如果需要纯字母数字（如短链接码），必须自己做拒绝采样映射，不能用 byte % 62
• buffer 长度建议一次申请到位，比如要 16 字符字符串，就 make([]byte, 16)，别反复小块读

别包装 rand.Reader，也别替换成 bytes.NewReader

有人为“避免全局状态”，把 rand.Reader 包进 struct 并在 init 时复制一份——这既没必要又危险。rand.Reader 本身就是线程安全的接口，底层是共享的熵源，复制它不会提升安全性，反而可能掩盖配置错误。

更严重的是，有人测试时用 bytes.NewReader(predefined) 替换 rand.Reader ——这在生产环境等于关掉安全开关，所有“随机”都变成可预测的固定序列。

• rand.Reader 是 io.Reader 接口，可以传自定义实现，但仅限调试或极端可控场景
• 生产代码里，永远用默认的 rand.Reader，不要动它
• 别把它套在 bufio.Reader 之类包装器里——Read 不需要缓冲，加了反而可能吞掉错误

最常被忽略的一点：错误处理不是仪式感。一次 rand.Read 调用失败，可能意味着 token 少了几个字节、密钥位数不足、甚至签名验证直接失败。宁可加个简单重试（最多 2–3 次），也不要 _ = rand.Read(buf) 一写了之。

今天关于《Golang安全随机数生成技巧分享》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！