Go crypto/rand 和 math/rand 怎么选：验证码、抽样与安全边界

登录接口需要一次性验证码时，随机数选错比代码写错更隐蔽：页面看起来能用，测试也能通过，但攻击者可能从时间种子、固定序列或可预测的重试规律里猜出下一组值。Go 的 crypto/rand 和 math/rand 都叫随机，真正的分界线却是“这个值被猜到以后会不会影响资产安全”。

验证码、找回链接、会话密钥和抽奖结果等不能被预测的值，用 crypto/rand；压测数据、模拟业务流量和可复现的测试样本，用 math/rand/v2。不要因为两者都能返回整数，就把它们当作可互换的工具。

先画清资产：同一个随机整数，风险等级可能完全不同

判断 API 之前，先把随机值放回业务流程。验证码会被提交到登录接口，找回链接会授予账号操作权，抽奖号码可能直接关联奖品；这些值一旦可预测，攻击者就能把“猜下一次结果”变成“绕过一次校验”。

这个表的关键不是“安全库永远更好”。安全随机源通常开销更高，也不提供“固定种子后每次得到同样序列”的测试便利。先判断资产和攻击路径，再选择工具，才不会把性能或可复现性问题带进错误的层次。

验证码和令牌：用 crypto/rand 生成原始字节

验证码不需要先生成一个很大的整数再格式化，直接取足够长度的随机字节，再编码成用户能输入的字符更容易检查长度。下面的示例使用十六进制令牌，返回 32 个随机字节，也就是 64 个十六进制字符。

package token

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

func NewToken() (string, error) {
    raw := make([]byte, 32)
    if _, err := rand.Read(raw); err != nil {
        return "", err
    }
    return hex.EncodeToString(raw), nil
}

这里有三个值得留意的边界。第一，rand.Read 返回错误时直接结束，不要偷偷换成普通随机源；第二，令牌长度要和数据库字段、URL 传输及过期时间一起确认；第三，服务端应保存令牌的摘要或一次性状态，而不是把明文令牌长期写入日志。

测试和压测：用 math/rand/v2 换取可复现样本

模拟订单、随机延迟和批量测试数据时，重点是覆盖分布和复现故障，不是防止外部猜测。Go 的 math/rand/v2 提供普通伪随机数生成能力，测试可以固定种子，让同一组输入在本地和 CI 中重复出现。

package sample

import "math/rand/v2"

func PickStatus() string {
    statuses := [...]string{"paid", "pending", "cancelled"}
    return statuses[rand.IntN(len(statuses))]
}

如果测试必须复现某次失败，把随机源作为依赖传入，并在失败日志里记录种子或样本版本。不要在生产请求处理中把全局伪随机源当作安全令牌发生器，也不要为了“看起来随机”把可复现测试改成系统随机源。

type Sampler struct {
    rng *rand.Rand
}

func NewSampler(seed1, seed2 uint64) *Sampler {
    return &Sampler{rng: rand.New(rand.NewPCG(seed1, seed2))}
}

func (s *Sampler) Index(size int) int {
    return s.rng.IntN(size)
}

最容易漏掉的攻击路径：把普通随机包在安全接口里

有些封装函数名字叫 NewCode、NewNonce 或 RandomString，调用方看不出底层来源。审查时不要只搜索 math/rand，还要沿着返回值的使用位置反向追踪：它是否进入 Cookie、密码重置 URL、签名输入、验证码表或抽奖结果。

1. 资产检查：标出会授权、认证、去重或产生奖品的字段。
2. 来源检查：确认安全字段只依赖 crypto/rand，普通样本只在测试或模拟边界出现。
3. 错误检查：让随机源不可用时暴露明确错误，不返回空串、固定值或时间拼接值。
4. 生命周期检查：令牌要有过期、一次性消费和失败次数限制，随机性不能替代业务防护。

上线前的验证清单：随机性之外还要看可观测性

安全随机数不能只用“连续生成一万个值没重复”来证明。重复概率、熵、编码长度和攻击模型不是同一件事。更实用的验收方式是把 API 选择、失败路径和业务生命周期放进同一组测试。

如果业务需要六位数字验证码，还要额外控制有效期、尝试次数和账号维度的限速。随机源解决的是“值难以预测”，不能单独解决暴力尝试、短信轰炸或泄露后的撤销问题。

常见问题

crypto/rand 生成的值一定不会重复吗？

不是数学上的绝对保证。增加随机字节数会显著降低碰撞概率，但业务仍应使用唯一约束、一次性消费和过期时间处理重复或重放。

测试里能不能直接调用 crypto/rand？

可以，但如果测试需要稳定复现某个边界样本，通常应把普通随机源作为依赖注入；安全随机更适合验证真实令牌流程，而不是生成固定测试夹具。

math/rand/v2 能不能用于抽奖？

如果结果会直接决定真实奖品或权益，不应只按“内部服务”判断。优先使用安全随机源，并补充公平性、审计、并发和重复领取控制。

只把字符串长度加长就安全了吗？

不够。长度、来源、编码、传输、日志、过期和尝试次数要一起看；一个很长但可预测的时间序列仍然不适合作为授权令牌。

把选择写进接口边界

Go 随机数的选择可以压缩成一句工程判断：值被猜到会不会影响安全资产？会，就让 crypto/rand 和明确的错误路径负责不可预测性；不会，且需要稳定复现，就用 math/rand/v2 管理样本。最后再把过期、限速、一次性消费和审计补齐，随机 API 才真正落在了正确的业务边界里。