Go crypto/rand 怎样为令牌读取不可预测字节

做登录会话、一次性链接或接口幂等键时，令牌的第一步不是“拼一段看起来随机的字符串”，而是先准备固定长度的随机字节。Go 的 crypto/rand.Read 会把切片完整填满，适合把令牌的安全预算直接写成 16、24 或 32 字节，再按传输场景编码。

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

令牌强度先由原始随机字节数决定，编码只改变可传输的表现形式。对多数服务端令牌，32 字节是清晰、容易复核的起点；不要把十六进制字符串的字符数误当成随机熵。

• 预算：先固定原始字节数，再讨论字符串长度。
• 实现：用 crypto/rand.Read 填满切片，不用时间、计数器或普通伪随机源拼接令牌。
• 编码：十六进制每个字节占两个字符，URL 安全 Base64 的长度更紧凑但规则不同。
• 指标：记录字节预算、编码长度、生成耗时和错误数，分别观察随机源与传输层。

先把令牌的随机预算写成字节数

我通常先把“令牌要多长”改写成“服务端要生成多少个原始随机字节”。例如 makeToken(32) 的预算是 32 字节，也就是 256 位原始随机数据；转成十六进制后会得到 64 个 ASCII 字符，但这两个数字代表的是不同维度。

这个拆分有助于避免两个常见误判：一是为了让 URL 看起来更长而无意义地追加固定前缀，二是把编码后的字符数当成熵。固定前缀可以帮助识别令牌类型，却不会增加不可预测性。

用 crypto/rand.Read 把缓冲区完整填满

实现可以保持很小：分配指定长度的字节切片，调用 rand.Read，再交给编码器。下面的函数只负责生成与编码，不把过期、撤销和权限判断混进随机源层。

package token

import (
	"crypto/rand"
	"encoding/hex"
)

// NewHexToken 生成固定字节预算的十六进制令牌。
func NewHexToken(byteLen int) string {
	// 令牌预算必须为正，避免调用方误传长度后得到空令牌。
	if byteLen 

这个版本的结果长度是确定的：输入 32 字节时，十六进制结果为 64 个字符。函数返回空字符串代表调用方没有给出有效预算；真实接口还应在业务层把这个分支记录为开发或配置错误，而不是把空值当成可用令牌。

编码长度要和传输场景分开看

十六进制的优势是规则直观、大小写策略容易统一，代价是每个字节需要两个字符。URL 安全 Base64 可以减少长度，但要固定是否带填充、允许哪些字符以及下游是否会再次转义。无论采用哪一种，原始字节数才是安全预算。

上线前用四个指标确认实现没有走偏

“生成成功”不等于“实现可长期观察”。在压测或灰度记录中，我会固定四个指标：原始字节数、编码后长度、单次生成耗时分布，以及随机源异常次数。前两个用于检查契约是否漂移，耗时用于发现异常阻塞，错误数用于确认故障是否集中在系统环境。

不要为了得到漂亮的吞吐数字而把随机源替换成普通伪随机数。令牌生成的核心结果是不可预测性，性能数据只能帮助判断当前字节预算和调用频率是否适合；如果必须优化，应先确认调用是否可以复用已生成令牌，而不是降低随机预算。

几个容易混淆的边界

为什么不用时间戳拼接用户 ID？

这些值通常可以被猜测或枚举，适合作为业务字段，不适合作为不可预测令牌的随机来源。令牌应由密码学安全随机源产生，业务绑定另行保存。

rand.Read 要不要像普通 IO 一样循环处理短读？

不需要按普通 io.Reader 的短读模型改写。官方文档明确说明 rand.Read 会完整填充传入切片；如果你直接使用其他 Reader，则应重新评估其读满语义和错误处理。

64 个十六进制字符是不是 64 字节安全性？

不是。64 个十六进制字符通常来自 32 个原始字节，字符只是编码后的表示。安全预算应记录原始字节数。

把随机预算、编码长度和业务生命周期拆开记录，令牌实现就更容易复查：crypto/rand.Read 负责填满安全随机字节，编码器负责可传输表示，业务层再负责过期、撤销和权限边界。