必须用 crypto/rand 生成安全随机字节，因其基于系统密码学熵源；math/rand 仅适用于非安全场景。需检查 crypto/rand.Read() 错误，避免模运算偏差，推荐拒绝采样法，并用标准编码（如 base64.RawURLEncoding）转换。
用 crypto/rand 生成字节，别碰 math/rand
Go 标准库里有两个 rand：一个在 math/rand，一个在 crypto/rand。前者是伪随机，种子固定就能复现；后者读取操作系统提供的密码学安全熵源（比如 Linux 的 /dev/urandom），适合生成 token、密钥、salt。如果你要的是“别人猜不到”，必须用 crypto/rand，否则哪怕字符串长度够长也没意义。
常见错误是顺手写了 math/rand.Intn() 拼字符——这在测试或日志 ID 场景可能凑合，但一旦用于 API key、重置链接、session id，就是安全漏洞。
-
crypto/rand.Read()直接填充字节切片，最常用也最可控 - 不要自己实现“从字母表里随机挑”逻辑，先生成原始字节，再映射到字符集（避免偏差）
- 如果调用失败（比如系统熵池暂时不可用），
crypto/rand.Read()会返回非 nil 错误，必须检查
字符集映射要避免概率偏差
直接对 crypto/rand 输出的字节模字符集长度（比如 byte % 62）会导致某些字符出现概率略高——因为 256 不整除 62，余数分布不均。虽然偏差小，但在高安全要求场景下不该存在。
推荐做法是“拒绝采样”：生成字节后，只接受落在合法区间内的值，跳过越界部分。Go 官方示例和主流库（如 golang.org/x/crypto/random 衍生工具）都采用这个策略。
立即学习“go语言免费学习笔记（深入）”；
- 例如用 62 字符集（a-z, A-Z, 0-9），每次取 1 字节，只接受
0–61范围；超出就丢弃，重读 - 实际性能影响极小，平均只需约 1.1 次读取就能获得 1 个有效字符
- 别用
strings.Map或循环替换，那是在已有字符串上修修补补，源头已不安全
rand.Read() 的 buffer 大小和错误处理不能省
crypto/rand.Read() 是底层字节读取，它不会自动重试或缓冲。你传入多大长度的切片，它就试图填满多少字节。如果系统临时无法提供足够熵（罕见但可能），它会返回 io.ErrUnexpectedEOF 或其他错误。
- 务必检查返回的
error，不能忽略；生产环境建议加简单重试（最多 2–3 次） - buffer 长度建议一次性申请到位，比如生成 32 字符字符串，就申请 32 字节切片，别反复小块读取
- 避免把
rand.Read()套在bufio.Reader之类包装器里——它不需要缓冲，反而可能掩盖错误
buf := make([]byte, 32)
if _, err := rand.Read(buf); err != nil {
// 处理错误，比如 log.Fatal(err) 或返回 fallback 错误
return "", err
}
别自己拼 Base64 / Hex，优先用标准编码
生成完随机字节后，常见需求是转成可打印字符串。有人手动查表映射字符，或者写 for 循环拼接——容易出错且难维护。
Go 标准库的 encoding/base64 和 encoding/hex 已针对安全性优化过编码逻辑，输出无歧义、无换行、可预测长度：
-
base64.RawURLEncoding.EncodeToString(buf)生成 URL-safe 字符串（不含+、/、=），适合 token -
hex.EncodeToString(buf)生成全小写十六进制，长度固定为字节数×2，适合调试或数据库存储 - 别用
fmt.Sprintf("%x", buf)，它慢且不保证小写一致性
真正麻烦的点不在生成，而在字符集选择和错误传播路径——比如没检查 Read() 错误，又用默认的 base64 编码，结果某次部署在容器里熵不足，token 全是空字符串，但日志里没报错。这种问题线上很难复现，得靠防御性编码提前卡住。
