crypto/rand.read()是go中生成密码学安全随机字节的唯一可靠入口，必须传入已分配长度的切片、检查错误、避免小块调用，并用rand.int(rand.reader, max)生成安全整数。
crypto/rand 是 Go 中唯一能用于密码学安全场景的随机数来源。只要你要生成 token、密钥、salt、验证码或任何不能被预测的值，就必须用它——math/rand 再快、再方便，也完全不适用。
crypto/rand.Read() 怎么用才不出错
crypto/rand.Read() 是最底层、最直接的安全字节获取方式，但它对调用姿势很敏感：
- 必须传入一个已分配好长度的
[]byte切片，比如buf := make([]byte, 32)；传nil或make([]byte, 0, 32)（cap ≠ len）会导致 panic - 返回值中的
n表示实际写入字节数，虽在主流系统中几乎总是等于切片长度，但仍需检查err：可能返回io.ErrUnexpectedEOF（如容器内熵池暂时不可用）、io.EOF或其他系统级错误 - 不要循环小块调用，例如反复
rand.Read([]byte{0})填满 32 字节——这会放大系统调用开销，且掩盖单次失败风险 - 它不扩容、不初始化、不重试，只负责“把真随机字节塞进你给的内存里”
常见错误现象：rand.Read(make([]byte, 32)) 看似正确，但如果漏掉 err 检查，一旦环境异常（如某些嵌入式或受限容器），token 就可能只填了一半却悄然通过，后续编码或使用时行为不可控。
为什么 crypto/rand.Int() 返回 *big.Int
rand.Int() 的签名是 func (r io.Reader, max *big.Int) (*big.Int, error)，它不返回 int 或 int64，这是刻意设计，不是 inconvenient：
- 密码学场景需要任意精度整数（比如生成 RSA 私钥时处理上千位数字），
*big.Int能无损表示、无溢出风险 - 避免开发者误用模运算引入偏差（
%在非 2 的幂范围内必然导致分布不均） - 强制显式转换，让范围语义清晰：比如
big.NewInt(100)明确表示 [0, 100)，而非模糊的 “100 以内”
典型误用：int(rand.Read(buf)) % 100 —— 这既绕过 rand.Int() 的拒绝采样逻辑，又因字节长度不足或截断引发 panic 或偏差。正确做法是：
- 生成 [0, 100) 整数：
nBig, err := rand.Int(rand.Reader, big.NewInt(100))，然后用nBig.Int64()转换（前提是max ≤ math.MaxInt64） - 若需 [1, 100]，写成
rand.Int(rand.Reader, big.NewInt(100)).Add(nBig, big.NewInt(1))，别用+1后再取模 - 不要自己实现“读 1 字节 → mod 62 → 查表”这种逻辑：要么用
rand.Int()，要么用拒绝采样（如读字节后丢弃 >61 的值）
生成 URL 安全令牌的惯用写法
生产中最常遇到的是生成 API key、重置链接 token 或 session ID，它们要满足：抗预测、URL 可携带、无歧义字符。- 直接用
base64.RawURLEncoding.EncodeToString(buf)，而不是base64.StdEncoding：前者不含+、/和填充符=，避免被代理或 URL 解析器截断或转义 - 切片长度按目标字符串长度反推：比如要 16 字符 URL 安全 token，
base64.RawURLEncoding编码效率是 3:4，所以应申请make([]byte, 12)（12×3/4=9，不够；12→16 字符刚好） - 不要用
fmt.Sprintf("%x", buf)：十六进制太长（32 字节 → 64 字符），且大小写敏感、易混淆（0/O, l/1）
容易踩的坑：有人封装一个 GenerateToken(n int) 函数，但内部仍用 math/rand 或忽略 err；还有人把 rand.Reader 包装成自定义 struct 并加锁——没必要，rand.Reader 是全局、线程安全的，直接用即可。
crypto/rand 和 math/rand 绝对不能混用的边界
二者不是“性能 vs 安全”的简单取舍，而是用途隔离：-
math/rand适合：单元测试中固定种子复现行为、游戏抽卡、负载均衡哈希、mock 数据生成 -
crypto/rand必须用于：JWT secret、AES key、bcrypt salt、OAuth code、短信验证码（防暴力撞库） - 兼容性上无问题，但语义冲突严重：比如用
math/rand生成的“随机” session ID，在高并发容器启动时可能因纳秒级时间戳重复，导致多个用户拿到相同 ID
真正复杂的地方在于：很多业务逻辑看似“只是个 ID”，实则承载了权限边界（如临时下载链接 token）。一旦误用 math/rand，漏洞不会立刻暴露，而是在渗透测试或日志审计时才被发现——那时修复成本远高于写对第一行 rand.Read()。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
