Go crypto/rand 的令牌字节生成方案

Go 生成登录链接、找回密码链接或一次性令牌时，核心步骤是先确定随机字节数，再让 crypto/rand.Reader 填满缓冲区，最后按传输场景编码。不要把 math/rand 的结果当作安全令牌，也不要把随机字节直接转换成字符串。

这篇文章只讨论标准库 crypto/rand 的令牌字节生成。官方文档地址：https://pkg.go.dev/crypto/rand

实用做法是把令牌长度定义为“原始随机字节数”，用 rand.Read 检查是否写入成功，再用无填充 URL 安全 Base64 输出。这样随机性、错误和输出格式各自有清楚的职责。

先按原始字节数确定令牌强度

令牌的不可预测性来自随机字节，而不是最终字符串看起来有多少个字符。比如 32 个随机字节有 256 位原始随机量，经过 URL 安全 Base64 后通常会变成约 43 个字符。编码只改变表现形式，不会凭空增加随机性。

工程上可以把字节数作为函数参数或常量，并在接口文档里写清楚。登录链接、短期一次性令牌和长期重置令牌的有效期不同，字节数也可以不同；不要为了凑固定字符串长度而截断编码结果。

用 crypto/rand.Read 填充固定长度缓冲区

crypto/rand 包实现加密安全的随机数生成器，包级 Reader 是可以并发使用的共享随机源。最直接的令牌字节生成方式是分配目标切片并调用 rand.Read：

package token

import (
    "crypto/rand"
    "fmt"
)

// RandomBytes 返回指定长度的加密安全随机字节。
// 长度由调用方决定，返回错误时不能继续使用未完成的缓冲区。
func RandomBytes(size int) ([]byte, error) {
    if size 

这里的返回值仍然要检查。标准库文档说明 rand.Read 会把随机数据写入切片并返回读取结果；即使常见平台上的随机源通常可用，接口也不应假定错误永远不会发生。

把随机字节编码成可放进 URL 的令牌

原始随机字节可能包含不可打印值和分隔符，适合存储或传输前先编码。若令牌要放入查询参数或路径，base64.RawURLEncoding 比普通 Base64 更省心：它使用 URL 安全字符集，并省略末尾的 = 填充。

package token

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

// NewURLToken 生成适合放在 URL 中的无填充随机令牌。
// size 表示原始随机字节数，不是最终字符串长度。
func NewURLToken(size int) (string, error) {
    if size 

不要把 []byte 直接写成 string(raw) 再拼到 URL 中。那只是按字节解释文本，可能包含不可见字符，也没有提供稳定的 URL 表示。编码后的长度取决于原始字节数和编码规则，调用方应保存或传输完整结果。

长度与错误处理要放在令牌接口边界

把校验放在生成函数内部，可以避免不同调用方对零长度、负数长度和随机源错误做出不一致处理。典型边界可以这样理解：

如果令牌用于身份验证，还要在服务端设置过期时间、一次性消费或撤销记录。随机生成只负责“难以猜测”，不负责权限、生命周期和业务状态。

常见问题

crypto/rand.Read 和 math/rand.Read 有什么区别？

crypto/rand.Read 面向加密安全随机数据，适合令牌、验证码种子和密钥材料等场景；math/rand 面向普通伪随机序列，适合模拟、抽样或可复现测试，不应作为安全令牌来源。

为什么 32 个字节编码后不是 32 个字符？

字节是原始数据单位，Base64 是把二进制转换成文本的编码方式。编码会产生长度膨胀，因此应在生成阶段按原始字节数衡量强度，在展示和传输阶段按编码后的长度处理。

可以只取 Base64 字符串的前几位吗？

不建议为了显示长度随意截断。如果确实需要较短令牌，应重新评估风险并从一开始选择合适的原始字节数、有效期和服务端防重放策略。

总结

Go 的令牌字节生成可以收敛为四步：确定原始字节数，调用 crypto/rand.Read，检查随机源错误，再用合适的编码输出。把随机性、格式和业务生命周期分开处理，接口会更容易复用，也更不容易把普通随机数或不完整缓冲区误当成安全令牌。