crypto/tls 不允许自定义随机数生成器，因其所有密钥材料生成均硬编码依赖 crypto/rand（操作系统熵源），这是为保障不可预测性与抗重放的安全契约；测试时应绕过随机路径或使用专用测试库，而非尝试替换 RNG。
crypto/tls 包本身不接受自定义随机数生成器。它内部硬编码依赖 crypto/rand（即操作系统熵源，如 /dev/urandom 或 Windows CryptGenRandom），所有密钥派生、nonce 生成、premaster secret 生成等关键步骤都直接调用 rand.Read 或 rand.Int，没有暴露配置接口。
你无法通过传参、选项结构体或环境变量替换它的 RNG —— 这不是设计疏漏，而是安全约束：TLS 协议实现必须使用密码学安全的随机源，而可插拔 RNG 容易引入侧信道、状态泄露或弱熵风险，标准库选择封闭这一层。
为什么 crypto/tls 不允许自定义 rand.Reader？
这是 TLS 实现的底层安全契约：
-
crypto/tls的所有密钥材料（如 client/server random、master secret、key block）都要求不可预测、高熵、抗重放； - 若允许用户传入任意
io.Reader（比如基于math/rand的 mock），会导致握手完全失去安全性，且错误难以检测； - Go 标准库将“安全随机性”视为基础设施级保障，而非可配置行为 —— 类似你不给
crypto/aes换底层 S-box 实现。
测试时想控制 TLS 随机行为怎么办？
你不能替换 RNG，但可以绕过部分依赖随机性的路径来测试逻辑：
立即学习“go语言免费学习笔记（深入）”；
- 对
tls.Config中的字段（如ServerName、NextProtos、MinVersion）做单元测试，这些不触发随机数调用； - 用
httptest.NewUnstartedServer+ 自定义net.Listener拦截握手字节流，验证 ClientHello 结构，而不实际完成 TLS 握手； - 若真需 deterministic 测试（例如 FIPS 模式验证或向量比对），应使用专门的测试库如
github.com/cloudflare/cfssl的 testutil，或 fork 并 patchcrypto/tls（仅限离线、非生产用途）。
注意：rand.Read 在测试中失败（如 /dev/urandom 不可用）会直接 panic，这不是 bug，而是安全 fail-fast 机制。
误以为能设置 rand.Reader 的常见来源
有人看到 crypto/tls 源码里有 rand.Read 调用，就以为像 http.Client 那样能传 Transport 一样注入 RNG —— 但实际没有对应字段或选项。搜索以下关键词在源码中均无结果：
randReaderRandomSourceRNGEntropySource
所有随机调用都是包级直接调用，无抽象层。
真正需要可控随机性的场景（如协议模糊测试、教学演示），应该在 TLS 之下建模：用 crypto/rand 生成固定字节序列后，手动构造 ClientHello，再喂给 tls.Conn 的底层 Conn（需反射或 unsafe 替换 reader），但这已脱离标准用法，且极易破坏内存安全。生产代码里，别试图绕过 crypto/rand。
