std::random_device未必真随机，Linux/macOS通常安全，Windows旧版可能退化；需用rd.entropy()>0断言验证，且仅用于生成种子而非高频调用。
std::random_device 未必真随机，先确认你的平台行为
Linux/macOS 上 std::random_device 通常读取 /dev/urandom，满足密码学安全；Windows（MSVC）早期版本可能退化为伪随机（如基于时间戳的 deterministic fallback），C++17 起要求必须抛出 std::runtime_error 而非静默降级——但实际仍需验证。
关键判断方式：调用 rd.entropy()，返回值接近 0 表示熵源不可靠（如 MSVC 19.28 未启用 bcrypt.dll 时可能返回 0）。
- 运行前加断言：
assert(rd.entropy() > 0.0); - 避免仅靠默认构造：
std::random_device rd{"default"};不如显式指定路径（Linux 可用"/dev/random"，但会阻塞） - Clang/libc++ 在 macOS 上使用
getentropy()，可靠；GCC 依赖内核支持，较新内核无问题
别直接用 std::random_device 当生成器，它不是设计来高频调用的
std::random_device 是熵源抽象，不是 PRNG。频繁调用 rd() 可能触发系统熵池耗尽（尤其在容器或 CI 环境），导致 read from /dev/random: Resource temporarily unavailable 或显著延迟。
- 正确做法：只用它生成一个高质量 seed，喂给高速 PRNG（如
std::mt19937_64） - 错误写法：
for (int i = 0; i —— 这是在榨干内核熵池 - 折中方案：每 N 次重播种（N ≥ 10000），但需配合原子计数器和 CAS，否则多线程下反而更慢
线程安全的随机池：用 thread_local + 静态初始化规避竞争
全局共享一个 PRNG 实例必然要加锁，而 thread_local 每线程一份，零同步开销。但注意：不能把 std::random_device 放在 thread_local 里——它本就不该被多次构造。
立即学习“C++免费学习笔记（深入）”；
thread_local static std::mt19937_64 gen([]{
std::random_device rd;
return rd(); // 单次调用，获取 64 位种子
}());
- 构造函数内联 lambda 确保每个线程只调用一次
rd() - 不要用
std::seed_seq包装单个值——它专为多整数 seed 设计，对单 uint64_t 是冗余开销 - 若需不同分布（如
std::uniform_real_distribution<double></double>），定义为静态局部变量或传入函数，避免重复构造
生产环境必须处理熵源失败，且不能静默回退
容器、chroot、某些云环境（如 AWS Lambda）可能禁用 /dev/random 访问，std::random_device 构造时抛异常或 entropy() == 0。此时应明确报错退出，而非自动切到 std::chrono::steady_clock::now().time_since_epoch().count() 这类弱种子。
- 启动时强制校验：
if (rd.entropy() - 日志中记录
rd.entropy()实际值，便于排查环境问题 - 测试阶段可用
std::random_device{"test"}（libc++ 支持）模拟失败，但生产代码里禁止硬编码字符串参数
硬件熵源不是“开了就稳”，它的可靠性取决于部署环境是否真正开放了内核熵接口。没验证过 entropy() 的代码，和没加盐的哈希一样危险。
