Go crypto/rand.Text 怎样生成固定长度的安全随机文本

我在给内部服务生成短令牌时遇到过一个看似简单的问题：想要密码学安全的随机文本，同时要求数据库字段始终保持固定长度。crypto/rand.Text() 很适合“给我一段安全随机文本”，但它的文档契约并不是“永远返回固定字符数”。因此，不关心精确长度时直接用 rand.Text；长度是协议字段时，自己用 crypto/rand.Read 映射到固定大小的字符表。

官方文档：https://pkg.go.dev/crypto/rand#Text

rand.Text 的长度语义到底是什么

rand.Text() 返回的是适合秘密字符串、令牌、密码等场景的密码学随机文本。它使用 RFC 4648 Base32 字母表，字符范围是大写字母和数字 2 到 7，不包含容易混淆的标点，也不带填充符。

当前 Go 源码按 ceil(128 / 5) = 26 个字符承载至少 128 位随机性，所以你现在观察到的结果通常是 26 个字符。但文档只保证“至少 128 位随机性”，并说明未来版本可能为了维持这一属性返回更长的文本。数据库列宽、URL 路由或外部协议如果要求严格长度，就不应直接依赖这个当前实现。

先用字符数换算你真正需要的熵

RFC 4648 Base32 有 32 个符号，一个字符最多携带 5 位随机信息。因此固定长度 N 的文本，理论熵上限是 5N 位。若希望达到和 rand.Text 相同的至少 128 位量级，通常选择 N >= 26；如果协议只需要展示短期、低权限的标识，也可以使用更短长度，但要把这个安全取舍写进接口约束。

这里讨论的是随机空间，不是令牌权限。即使随机性足够，令牌仍应设置过期、撤销、最小权限和安全存储策略；本文不把随机文本生成函数扩展成完整的认证方案。

严格固定长度时自己控制 Base32 映射

下面的函数每生成一个字符就消耗一个随机字节的低 5 位，因此返回值恰好是 length 个字符。byte & 31 等价于保留低 5 位；由于一个字节的 256 种取值可以平均分成 32 组，不会像对非整除范围做简单取模那样产生偏差。

package token

import (
	"crypto/rand"
	"errors"
)

const base32Alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"

// FixedText 返回恰好 length 个 RFC 4648 Base32 字符。
func FixedText(length int) (string, error) {
	if length 

这个实现的固定长度是明确的，但它也把责任交给调用方：length=26 才能提供至少 128 位量级的随机空间，length=8 只能得到 40 位。不要为了迎合页面字段长度，盲目把秘密令牌截短。

生产环境要把长度、日志和版本一起管住

如果项目只支持 Go 1.24 及以上，且调用方不依赖精确长度，rand.Text 是更容易维护的最小 API。若数据库迁移、URL 模板或第三方协议要求固定宽度，则把长度常量、字符表和目标熵写在同一个包里，并为返回值保存非敏感的长度信息，而不是打印令牌本身。

• 不要用 math/rand、时间戳或自增 ID 替代密码学随机源。
• 不要把完整令牌写入日志、错误消息、埋点或测试快照；需要关联时记录哈希或内部 ID。
• 不要把 rand.Text 当前返回 26 个字符当成未来版本承诺；跨版本协议优先使用固定长度函数。
• 发生随机源错误时让上层明确失败，不要用固定字符串、零值或时间值兜底。

常见问题

rand.Text 能不能通过截取前 N 个字符实现固定长度？

不建议。截取会减少随机空间，而且把未来可能变长的输出再次截断，容易让安全预算和接口意图分离。需要固定长度时，从一开始就按 N 个字符生成。

为什么不是直接用 base32.StdEncoding.EncodeToString？

标准 Base32 编码按字节组编码，输出长度还会受输入字节数和填充影响。它适合编码已有字节序列；本文函数的目标是直接产生恰好 N 个字符，因此显式生成 N 个 5 位符号更直观。

26 个字符是否代表任何令牌都安全？

它只表示随机空间达到至少 128 位量级，不代表令牌没有过期、权限过大、泄露或重放问题。认证系统仍需设计生命周期、存储、撤销和访问控制。

结论可以压缩成一句话：不要求固定长度就使用 rand.Text，要求协议字段稳定就用密码学随机字节按 32 字符表生成 N 个字符，并用 5N 位熵检查长度是否足够。