Go crypto/rand.Text 的长度为什么不是固定字符数

crypto/rand.Text() 当前实现返回的是 26 个 ASCII 字符，但这不是调用方可以永久依赖的固定长度承诺。官方文档真正保证的是：结果使用 RFC 4648 Base32 字母表，并且至少包含 128 位随机性；文档还明确说，未来版本可能为了维持这些性质返回更长的文本。

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

当前看到的 26 个字符，为什么不是固定契约

很多代码第一次打印 rand.Text() 时会得到长度为 26 的字符串，于是顺手把数据库字段设成 CHAR(26)，或者在接口文档里写死 26 位。这个做法把“当前版本的输出形状”误当成了 API 约定。

Text 的文档重点是用途和安全强度：它面向 secret、token、password 等文本场景，结果至少有 128 位随机性，碰撞概率和暴力猜测风险都足够低。为了继续满足这个保证，未来实现可以增加长度。因此兼容代码应该允许字段变长，校验也应检查字符集和最小安全强度，而不是只接受 26。

26 这个数字来自 Base32 映射，而不是字符数参数

当前源码把 ⌈log₃₂ 2¹²⁸⌉ 计算为 26，先创建 26 字节缓冲区，再读取安全随机源；每个字节取模 32，映射到 ABCDEFGHIJKLMNOPQRSTUVWXYZ234567，最后转成字符串。因为这套字母表全部是单字节 ASCII，当前实现下 len(text) 与 utf8.RuneCountInString(text) 都是 26。

这里没有“传入长度”的参数，也没有承诺每个 Go 版本永远使用 26。另一个容易混淆的点是：26 个 Base32 字符承载的编码容量高于 128 位，所以它不是“26 个字符等于 26 位随机数”。看长度时，要把输出表现形式和熵预算分开。

业务要求固定长度时，显式设计编码边界

如果数据库、外部协议或二维码字段确实要求固定宽度，不要先调用 rand.Text() 再截断。可以先确定需要的随机字节数，再选择十六进制或 URL-safe Base64。下面的示例生成固定 16 字节，并用无填充 Base64URL 得到固定 22 个 ASCII 字符；它的随机性预算与截断后的文本不同，不能只看字符串长度。

package token

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

func FixedToken() (string, error) {
	// 16 个随机字节提供 128 位随机性，长度由字节数明确控制。
	raw := make([]byte, 16)
	if _, err := rand.Read(raw); err != nil {
		return "", fmt.Errorf("read secure random bytes: %w", err)
	}

	// RawURLEncoding 不使用填充符，16 字节稳定编码为 22 个 ASCII 字符。
	return base64.RawURLEncoding.EncodeToString(raw), nil
}

固定长度并不等于可以忽略协议边界：Base64URL 的字符集与十六进制不同，接收端必须使用同一编码；如果字段只允许数字或小写字母，还要重新计算可用字符集和所需长度。更不要通过取模把随机字节直接压到一个很小的字符表，那会造成分布偏差，除非实现了正确的拒绝采样。

落库和接口设计的检查清单

排查“长度不一致”时，先确认 Go 版本、调用的是不是 crypto/rand.Text、测量的是字节还是字符，以及中间是否经过了 JSON、URL 或数据库层。若只是想判断是否为合法结果，优先校验 RFC 4648 Base32 字符集与业务允许的最小长度；不要把长度变化直接判定为随机源失效。

相关问题

rand.Text() 适合当密码吗？

它的文档用途包含 password 文本场景，但账号密码仍要结合密码策略、哈希存储和重置流程设计；不要把随机生成与密码存储混为一件事。

能不能把 rand.Text() 截成 12 位？

不建议。截断会降低随机性，且最终强度取决于保留下来的字符和生成分布；固定宽度场景应直接按目标熵预算生成并编码。

为什么不用 math/rand 生成 token？

token、重置链接和会话密钥需要不可预测的随机源，应使用 crypto/rand；math/rand 面向非密码学随机场景。