Go crypto/rand 随机源的测试替换方案与生产边界

如果令牌生成函数直接写死 crypto/rand.Read，测试很难稳定覆盖固定字节、编码边界和读取错误。更稳妥的做法是让业务函数接收一个 io.Reader：生产入口传入 crypto/rand.Reader，测试用例传入可重复或故意报错的 Reader。

官方文档：https://pkg.go.dev/crypto/rand

先把随机源从业务函数参数化

令牌函数真正需要的是“读取 n 个字节的能力”，而不是某个具体包。把依赖缩小到 io.Reader 后，生产和测试只在组装层做选择，业务逻辑保持一致。

package token

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

// Generator 持有随机源；生产实例使用 crypto/rand.Reader。
type Generator struct {
    reader io.Reader
}

// NewGenerator 让调用方显式决定随机源，避免业务函数偷偷切换算法。
func NewGenerator(reader io.Reader) (*Generator, error) {
    if reader == nil {
        return nil, fmt.Errorf("random reader is nil") // 拒绝未配置的安全依赖。
    }
    return &Generator{reader: reader}, nil
}

// NewToken 读取固定长度字节并编码为无填充 Base64URL 令牌。
func (g *Generator) NewToken(size int) (string, error) {
    if size 

这里显式使用 io.ReadFull，是因为可替换 Reader 可能短读或返回错误。官方文档说明 crypto/rand.Reader 是可并发使用的全局安全随机源，而 rand.Read 出错时会让程序不可恢复地退出；业务层需要可测试错误分支时，直接处理传入 Reader 更合适。

在生产入口固定使用安全随机源

生产代码只需要在组装阶段调用 NewProductionGenerator。不要为了让测试更容易而把 math/rand、时间戳或自定义可预测种子塞进默认路径。math/rand 的定位是可重复的伪随机序列，适合模拟和非密码用途，不适合生成会话令牌、重置链接或验证码密钥。

如果项目使用依赖容器或 HTTP Handler，可以在应用启动处创建一次生产 Generator，再把它传给服务对象。这样安全边界在构造代码中可见，测试也不需要修改包级变量。

在测试中注入可重复的随机字节

测试不需要等待“碰巧生成某个结果”，只要准备足够的字节并断言结果即可。无填充 Base64URL 不包含 +、/ 和末尾填充符，适合放在 URL 中；但编码长度仍由原始字节长度决定，断言时应围绕输入长度编写。

func TestNewToken(t *testing.T) {
    // 固定输入让失败时可以直接复现，不把测试字节当作生产密钥。
    reader := bytes.NewReader([]byte("0123456789abcdef"))
    generator, err := NewGenerator(reader)
    if err != nil {
        t.Fatal(err) // 构造失败时停止当前用例。
    }

    got, err := generator.NewToken(16)
    if err != nil {
        t.Fatal(err) // 读取或编码失败都应明确暴露。
    }
    if got != "MDEyMzQ1Njc4OWFiY2RlZg" {
        t.Fatalf("unexpected token: %q", got) // 固定输入对应固定编码。
    }
}

func TestNewTokenReaderError(t *testing.T) {
    // 通过只返回错误的 Reader 覆盖底层随机源故障分支。
    generator, err := NewGenerator(errorReader{})
    if err != nil {
        t.Fatal(err)
    }
    if _, err := generator.NewToken(16); err == nil {
        t.Fatal("expected random reader error") // 不能把安全源故障吞掉。
    }
}

示例中的固定字节只用于断言算法和编码，不代表安全随机性。真实测试还应覆盖 size == 0、Reader 字节不足和 Reader 返回错误三类边界；不要为了“测得稳定”而把固定源挂到全局变量上。

把错误和并发边界写进测试设计

bytes.Reader 会随着读取推进状态，不应被多个并发测试共享。每个用例创建自己的 Reader，或者在测试夹具中按用例返回新的 Generator。生产的 crypto/rand.Reader 可以并发使用，但 Generator 内部若改成带状态的自定义 Reader，就必须重新评估并发安全性。

另一个容易误判的点是“替换全局 rand.Reader”。这会影响同一进程内其他测试和并发请求，还可能让生产组装被悄悄污染。依赖注入的好处正在于替换只发生在对象边界，不需要恢复全局状态。

发布前复查安全随机没有被替换

可以沿着三处检查：生产构造函数是否唯一传入 rand.Reader；测试是否只通过 NewGenerator 注入固定或错误 Reader；业务代码是否没有直接调用 math/rand 或时间戳生成秘密。这样既能测试错误，也不会把测试便利误带进正式路径。

常见问题

为什么不直接在测试里改 crypto/rand.Reader？

它是全局共享变量，修改会扩大影响范围并产生并发污染。把 Reader 作为参数传入更容易恢复、复用和审查。

测试 Reader 需要实现完整的随机算法吗？

不需要。单元测试只需实现 io.Reader，提供固定字节或可控错误；安全随机性由生产环境的 crypto/rand.Reader 保证。

什么时候可以使用 math/rand/v2？

模拟、抽样、洗牌和可复现测试等非密码场景可以使用；会话令牌、验证码密钥和重置链接仍应使用 crypto/rand。