Go crypto/rand 如何生成不可预测的随机字节

给登录链接、邮箱验证或会话令牌取随机值时，优先使用 Go 标准库的 crypto/rand，不要用 math/rand 代替。最短的做法是分配固定长度的字节切片，再调用 rand.Read；它会填满切片，随后用 base64.RawURLEncoding 编码，得到适合放进 URL 的字符串。

官方地址：https://pkg.go.dev/crypto/rand

普通业务直接用 rand.Read 生成固定长度字节即可；只有在注入自定义 io.Reader、编写故障测试或需要观察底层错误时，才改用 io.ReadFull 并显式检查错误。

生成随机字节并编码成令牌

这里先做一个够小、也容易复用的函数。rand.Read 作用在已经分配好的切片上，成功后 n 应等于切片长度。示例把随机字节编码成不带填充符的 URL 安全 Base64，令牌不会因为 +、/ 或尾部 = 影响链接传递。

package main

import (
    "crypto/rand"
    "encoding/base64"
    "fmt"
)

func newToken() (string, error) {
    // 固定 32 字节，令牌的随机空间来自这里，而不是编码后的字符数。
    raw := make([]byte, 32)
    // rand.Read 会填满 raw；返回错误时不要继续使用不完整的数据。
    if _, err := rand.Read(raw); err != nil {
        return "", fmt.Errorf("读取安全随机字节: %w", err)
    }
    // RawURLEncoding 适合放到查询参数或路径中，并省略尾部填充符。
    return base64.RawURLEncoding.EncodeToString(raw), nil
}

这里的错误分支按接口习惯保留，便于以后把实现替换成可注入 Reader；在当前 Go 文档里，默认 rand.Read 会填满目标切片且不会返回错误，底层默认随机源发生不可恢复错误时程序会终止。因此调用方不应把返回值当成“可能只填了一半”的普通读取。

字节长度和编码格式怎么选

字节数先按安全目标决定，再考虑字符串长度。32 字节通常适合会话令牌和一次性链接；如果协议已有更短的密钥空间要求，可以单独评估，不要为了省几个字符随意截断。Base64 只是表示层，不会增加随机性。

令牌长度检查也很简单：生成后检查字节切片长度，不要通过打印令牌来判断成功。日志里最多记录请求编号、字节长度和错误类型，不能记录完整秘密值。

什么时候需要显式处理读取错误

如果函数接受一个外部传入的 io.Reader，就不能假定它拥有默认 rand.Reader 的保证。测试中可以注入 faultReader 或 errRandomSource，让底层返回错误，再用 io.ReadFull 检查是否填满目标缓冲区。

package token

import (
    "crypto/rand"
    "fmt"
    "io"
)

func readBytes(src io.Reader, size int) ([]byte, error) {
    // size 来自调用方，先拒绝无意义的负数，避免分配前才发现问题。
    if size 

这个版本把“随机源”作为依赖传入，所以测试可以用会立即返回错误的替身验证业务分支。生产代码则把 rand.Reader 作为默认实现。不要为了捕获极少见的底层错误而退回 math/rand；如果安全随机源失败，返回错误或让进程按标准库策略停止，都比悄悄降级可靠。

发布前的检查清单

• 秘密值来自 crypto/rand，而不是 math/rand 或时间戳拼接。
• 原始字节长度在代码中是明确数字或配置，不通过截断编码字符串凑长度。
• 生成失败时返回错误；不记录完整令牌，也不生成备用的可预测值。
• 测试需要失败分支时注入 io.Reader，用 io.ReadFull 验证短读和错误。

相关问题

crypto/rand 和 math/rand 可以互换吗？

不能。前者用于不可预测的安全随机值，后者适合模拟、抽样和可复现实验；认证令牌不应依赖后者。

为什么生成了随机字节还要 Base64 编码？

字节可以包含不可见值，Base64 只是把它转换为可传输文本；安全强度由编码前的字节长度决定。

rand.Read 返回的 n 要不要检查？

默认 rand.Read 会填满切片；采用可注入 io.Reader 时，应使用 io.ReadFull 并同时检查返回错误。