crypto/rand.Read 是 Go 中生成密码学安全随机字节的唯一正确方式，必须传入已分配长度的切片、检查 error、避免模偏差，并使用拒绝采样或 rand.Int 生成安全整数；严禁使用 math/rand 或错误包装 rand.Reader。
crypto/rand.Read 是生成安全随机字节的唯一正路
别碰 math/rand，它和“安全”两个字毫无关系——种子一固定，整个序列就可复现，API key、session id、密码重置令牌用它等于裸奔。
crypto/rand.Read 才是 Go 里真正从操作系统熵池（比如 Linux 的 /dev/urandom）读取不可预测字节的函数。它不生成 int，不拼字符串，只干一件事：把随机字节塞进你给的切片里。
- 必须传入已分配长度的切片，例如
buf := make([]byte, 32)；传nil或未初始化切片会 panic - 必须检查返回的
error：虽然罕见，但系统熵暂时不足时可能返回io.ErrUnexpectedEOF，忽略它可能让 token 只填了一半 - 别对同一
[]byte多次调用Read以为“更随机”——单次已满足密码学强度，重复调用没意义，还可能掩盖错误
生成安全整数不能用模运算，要用 rand.Int 或拒绝采样
想生成 [0, 100) 的随机整数？别写 int(rand.Read(...)) % 100 ——这是经典模偏差（modulo bias），因为 256 不整除 100，余数 0~99 分布不均，小数字概率略高。
正确做法只有两种：
立即学习“go语言免费学习笔记（深入）”；
- 用
rand.Int(rand.Reader, big.NewInt(100))：它内部已实现拒绝采样，保证均匀，返回*big.Int，小范围直接转.Int64()即可（只要max ≤ math.MaxInt64） - 自己手写拒绝采样：比如字符集长 62，每次读 1 字节，只接受
0–61，超出就丢弃重读；平均 1.1 次就能拿到一个有效值，性能无感 - 若 n 是 2 的幂（如 256、65536），可用位运算截取：
binary.LittleEndian.Uint64(buf) & (n-1)，但仅限此场景，别滥用
生成随机字符串别拼字母表，先填字节再编码
常见错误是循环调用 rand.Intn(len(alphabet)) 拼字符串——这要么用了 math/rand，要么用了 crypto/rand 但没处理模偏差，源头就不安全。
正确路径永远是：生成原始字节 → 映射到目标字符集（用拒绝采样）→ 编码输出。
- 避免
base64.StdEncoding：含+和/，URL 或 HTTP header 里会被代理误解析；=填充符也可能被截断 - 优先用
base64.RawURLEncoding：无符号、无填充，适合 token、文件名、JWT - 如果需要纯字母数字（如短链接码），必须自己做拒绝采样映射，不能用
byte % 62 - buffer 长度建议一次申请到位，比如要 16 字符字符串，就
make([]byte, 16)，别反复小块读
别包装 rand.Reader，也别替换成 bytes.NewReader
有人为“避免全局状态”，把 rand.Reader 包进 struct 并在 init 时复制一份——这既没必要又危险。rand.Reader 本身就是线程安全的接口，底层是共享的熵源，复制它不会提升安全性，反而可能掩盖配置错误。
更严重的是，有人测试时用 bytes.NewReader(predefined) 替换 rand.Reader ——这在生产环境等于关掉安全开关，所有“随机”都变成可预测的固定序列。
-
rand.Reader是io.Reader接口，可以传自定义实现，但仅限调试或极端可控场景 - 生产代码里，永远用默认的
rand.Reader，不要动它 - 别把它套在
bufio.Reader之类包装器里——Read不需要缓冲，加了反而可能吞掉错误
最常被忽略的一点：错误处理不是仪式感。一次 rand.Read 调用失败，可能意味着 token 少了几个字节、密钥位数不足、甚至签名验证直接失败。宁可加个简单重试（最多 2–3 次），也不要 _ = rand.Read(buf) 一写了之。
