Go crypto/rand.Text 为什么生成结果只包含字母和数字

我第一次把 crypto/rand.Text() 打进日志时，直觉上把它当成了“安全版的随机字母数字串”：长度看着固定，内容也只有大写字母和数字。后来为了让邀请码同时支持小写字母和 0，我才发现，这个判断并不准确。

rand.Text 返回的是基于 RFC 4648 Base32 字符表的密码学安全文本。当前实现使用大写字母 A-Z 和数字 2-7，所以小写字母、0、1、8、9 不会出现。官方文档还说明它至少提供 128 位随机性，未来版本可能按需要返回更长的文本。

先看现象：为什么没有小写字母和 0、1、8、9

先跑一个最小例子，观察几次输出：

package main

import (
    "crypto/rand"
    "fmt"
)

func main() {
    // Text 使用密码学安全随机源生成适合令牌的文本。
    token := rand.Text()
    fmt.Println(token)
}

你会看到类似 JBSWY3DPEHPK3PXP2VY7KQ5M6A 的结果。它看起来像“字母加数字”，但字符集合其实已经被限定：字母只有大写，数字只有 2 到 7。这不是随机性不足，也不是日志截断，而是 API 主动选择了更适合口述、复制和作为秘密文本使用的编码表。

图：rand.Text 的输出范围由 Base32 字符表决定，而不是任意字母数字集合。

源码里的 32 个字符决定了输出范围

对照官方源码会更直观：字符表定义为 ABCDEFGHIJKLMNOPQRSTUVWXYZ234567，随后每个随机字节通过 % 32 映射到这 32 个位置。也就是说，结果中出现哪些字符，首先由字符表决定；随机源负责的是从这些位置中安全地选出结果。

当前实现为 26 个位置准备随机字节，这是因为 26 个 Base32 字符可以承载至少 128 位随机性。这里要分清两个结论：第一，当前版本的实现长度是 26；第二，官方文档保留了未来增长长度的空间。因此可以把它当作安全文本生成 API，却不要把 26 写进跨版本协议或数据库校验规则，除非你已经把长度作为自己的业务约束处理。

官方资料：https://pkg.go.dev/crypto/rand#Text；当前实现：https://go.dev/src/crypto/rand/text.go。

需要自定义字符集时，不要直接改 rand.Text

如果需求是“只允许大写字母和数字”“排除容易混淆的字符”或“必须包含一组业务字符”，那就不要把 rand.Text 的结果再做字符串替换。替换会改变分布，甚至可能让长度和碰撞分析变得含糊。更清晰的做法是保留安全随机源，直接对自己的字符表做均匀索引。

package token

import (
    "crypto/rand"
    "errors"
    "math/big"
)

func RandomText(alphabet string, length int) (string, error) {
    // 先约束字符表和长度，避免产生不可解释的输出。
    if alphabet == "" || length 

这个版本的重点不在函数名，而在边界明确：字符表是输入，长度是输入，随机源仍然是 crypto/rand.Reader，每次索引由 rand.Int 产生。如果字符表包含多字节 Unicode 字符，应先按 []rune 处理，再按 rune 数量建立上界；上面的示例更适合 ASCII 字符表。

图：自定义字符集合时，使用 rand.Int 选择均匀索引，避免把安全随机源降级成普通随机数。

把字符集合、随机性和长度分开判断

我现在会先问一句：这个字段到底需要“Go 提供的安全文本”，还是需要“业务定义的字符协议”？前者直接用 rand.Text 很省心；后者就把字符表、长度和错误处理写成自己的小函数。这样排查结果时，不会把编码规则、随机性和版本实现混成一个问题。

常见问题

为什么不能把 rand.Text 当成完整的字母数字生成器？

因为它采用的是 RFC 4648 Base32 字符表，只有大写 A-Z 与 2-7。如果业务明确要求小写字母或数字 0、1，应使用自定义字符表。

当前版本是不是永远返回 26 个字符？

当前实现是 26 个字符，但官方文档允许未来为了满足随机性需求返回更长的文本。跨版本存储或协议应由业务自行定义长度边界。

自定义字符表能不能直接对随机字节取模？

不建议把简单取模当作通用方案。字符表长度不是随机字节取值范围的整除因子时会引入分布偏差，使用 rand.Int 让上界与字符表长度直接对应更容易审查。