Go crypto/rand 为什么字符串长度不等于字节数

Go 的 crypto/rand 生成的是随机字节，不是“随机字符”。所以你申请 n 个字节后，直接执行 string(buf)，得到的字符串长度通常是 n 个字节，但它未必包含 n 个可见字符；如果再做十六进制或 Base64 编码，最终字符串还会按编码规则变长。

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

排查这类问题时，先写清楚“长度”指的是原始随机字节数、Go 字符串的字节数、Unicode 码点数，还是接口最终接收的 ASCII 字符数。生成 token、验证码和 URL 参数时，优先随机取字节，再用明确的文本编码。

crypto/rand 返回的到底是什么

crypto/rand.Read 把随机数据写入调用方提供的 []byte。它的输出范围是 0 到 255 的字节值，并不承诺这些值拼起来是合法 UTF-8，更不承诺每个字节都对应一个适合展示的字符。这个包的职责是提供密码学安全的随机源，文本格式需要由应用层决定。

package main

import (
	"crypto/rand"
	"fmt"
)

func main() {
	buf := make([]byte, 12)
	// Read 填满 buf；返回的 n 是随机字节数量，err 必须被处理。
	n, err := rand.Read(buf)
	if err != nil {
		panic(err)
	}

	s := string(buf)
	fmt.Printf("randomBytes=%d stringBytes=%d runes=%d\n", n, len(s), len([]rune(s)))
}

在这段代码里，len(s) 统计字符串底层的字节数，len([]rune(s)) 统计成功解码出的 Unicode 码点数量。随机字节中可能夹杂无效 UTF-8，转换为 rune 时会出现替换字符，因此后者不能用来反推随机源生成了多少字节。

为什么直接转成 string 会让“字符长度”看起来不对

Go 字符串本质上是只读字节序列。对 ASCII 文本而言，一个字符通常占一个字节，因此很多人会把 len 的结果误认为字符数；但随机字节没有这个保证。打印时，控制字节、不可打印字节或非法 UTF-8 还可能被终端替换、转义或显示成不可见内容。

因此，下面的写法只适合你明确需要一个任意字节串，并且后续 API 允许二进制数据的场景：

func randomBytes(size int) ([]byte, error) {
	// 先拒绝负数，避免 make 触发 panic。
	if size 

如果目标是 JSON、Header、Cookie、URL 或日志中的文本，应该先选一个明确的 ASCII 编码。不要为了让输出“看起来像字符”而过滤随机字节；过滤会改变分布，还可能导致长度不足。

十六进制和 Base64 的长度规则不同

十六进制把每个字节表示成两个字符，所以 n 个随机字节会得到 2n 个 ASCII 字符。Base64 每 3 个字节编码成 4 个字符，带标准填充时长度是 4 * ceil(n/3)；URL 安全的 RawURLEncoding 会省略填充，长度会略有不同。

package main

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

func main() {
	buf := make([]byte, 16)
	// 16 个随机字节可编码为 32 个十六进制字符或 24 个 Base64 字符。
	if _, err := rand.Read(buf); err != nil {
		panic(err)
	}

	fmt.Println("hex:", hex.EncodeToString(buf))
	fmt.Println("base64:", base64.RawURLEncoding.EncodeToString(buf))
}

这里的长度变化不是 crypto/rand 多生成了数据，而是展示层编码的结果。若协议要求固定 32 个字符，可以直接生成 16 个字节后使用十六进制；若更在意相同熵下的字符串短一些，可以使用 URL 安全 Base64，但要确认接收方允许其中的字符集。

需要固定文本长度时应该怎么写

先确定最终文本的字符集，再按编码后的长度反推随机字节数。下面的函数生成固定 32 个十六进制字符，适合需要可复制文本的标识场景；它返回错误而不是静默使用弱随机源。

func randomHexChars(chars int) (string, error) {
	// 一个字节对应两个十六进制字符，奇数长度无法直接整齐编码。
	if chars 

如果使用 Base64，需要用 EncodedLen 或实际编码结果决定长度，而不是把“字节数”直接当成“字符数”。对于验证码这类面向人的文本，还要另外设计字符表和拒绝歧义字符的策略，不能把任意二进制随机串直接展示给用户。

长度不符时按这张表排查

常见问题

crypto/rand.Read 生成 10 个字符应该传 10 吗？

如果指 10 个原始字节，可以传 10；如果指 10 个十六进制字符，应传 5 个字节；如果指 10 个 Base64 字符，则要按编码结果实际截取，并重新评估熵与填充规则。

为什么不把随机字节限制到字母数字范围？

逐字节取模会造成偏差，尤其是字符表长度不能整除 256 时。需要指定字符集时，应使用拒绝采样或成熟的安全随机字符串实现，并保留错误处理。

len([]rune(s)) 能不能当成字符串长度？

它只能表示 UTF-8 解码后的 Unicode 码点数量，适合部分文本处理，不等同于用户感知的字素数量，也不适合衡量随机二进制的原始长度。

小结

crypto/rand 负责产生安全随机字节，长度问题通常发生在“字节转文本”的下一步。直接转 string 得到的是字节序列；十六进制会变成两倍长度；Base64 按分组扩展。把原始长度、编码后长度和展示字符数分开定义，再选择匹配协议的编码，就不会再把随机字节数误认为字符串字符数。

参考资料：crypto/rand 官方文档、encoding/base64 官方文档、Go 官方博客：Strings, bytes, runes and characters。