当前位置：首页 > 文章列表 > Golang > Go问答 > Go crypto/rand.Text 的长度为什么不是固定字符数

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

来源：17golang原创 2026-10-04 08:14:56 0浏览收藏

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

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

要点速览

当前 Go 标准库源码用 26 个随机字节映射出 26 个 Base32 字符。
26 是当前实现细节，稳定依赖应放在“至少 128 位随机性”和字符集语义上。
业务若需要固定长度，应显式选择字节数与编码方式，不能把 rand.Text() 截断后当成等价方案。

当前看到的 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 crypto/rand.Text、随机读取、26字节缓冲区和RFC 4648 Base32字母表的静态关系 — 图1：结构说明图，展示 rand.Text 当前实现中的随机源、26 字节缓冲区与 Base32 字符映射关系，不是运行截图。

这里没有“传入长度”的参数，也没有承诺每个 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 固定随机令牌中原始随机字节、Base64URL编码、字符长度和128位随机性的静态关系 — 图2：边界说明图，比较显式字节预算与 Base64URL 输出长度的关系，不代表程序运行结果。

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

需求	建议	不要做
普通一次性 secret	直接保存 rand.Text()，按官方语义允许未来变长	把 26 写成跨版本协议
固定宽度 token	先定随机字节数，再固定编码方案	生成 Text 后截断
外部系统传递	记录字符集、填充规则和最大长度	只记录“随机字符串”
数据库字段	按编码后的最大长度留余量并做字符集校验	用当前样本长度推导永恒上限

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