std::mt19937 并非总是最快，因其初始化和单次生成略重；对吞吐量敏感场景可选 std::minstd_rand（快但周期短）或 std::ranlux24（统计质量高但慢2–3倍）。
直接用 std::uniform_int_distribution 配合 std::mt19937 是安全且足够快的，但“高性能”不等于“默认配置”，关键在引擎选择、分布复用、线程隔离和种子策略——多数性能问题其实出在误用上，而非库本身慢。
为什么 std::mt19937 不总是最快？
它质量高、周期长（2¹⁹⁹³⁷−1），但初始化和单次生成略重；对吞吐量敏感的场景（如每秒亿级随机数），std::minstd_rand 或 std::ranlux24 可能更合适：
-
std::minstd_rand：周期 2³¹−1，生成极快，适合非密码学、非统计敏感场景（比如游戏逻辑、哈希扰动） -
std::ranlux24：跳步强随机，但比mt19937慢 2–3 倍，仅当需要更高统计质量时启用 - 避免在循环内重复构造引擎——引擎是状态机，构造开销远大于生成调用
分布对象必须复用，不能每次 new 一个
std::uniform_int_distribution 构造本身无状态，但内部可能缓存归一化参数；频繁构造会触发浮点计算和分支判断，实测在 GCC 13 + -O2 下，循环内新建分布比复用慢 15%–25%：
// ❌ 错误：每次调用都构造
int bad_rand(int a, int b) {
std::random_device rd;
std::mt19937 gen(rd());
std::uniform_int_distribution<int> dist(a, b); // 每次都算 (b-a+1) 和逆
return dist(gen);
}
// ✅ 正确：分布对象复用（注意线程安全）
thread_local std::mt19937 gen{std::random_device{}()};
thread_local std::uniform_int_distribution<int> dist{0, 100};
int good_rand() { return dist(gen); }
多线程下别共享同一个 mt19937 实例
std::mt19937 非线程安全——没有内部锁，也没有原子状态更新；共享会导致生成序列错乱、重复甚至未定义行为（尤其在 gen() 调用被编译器重排时）：
立即学习“C++免费学习笔记（深入）”；
- 用
thread_local是最简单可靠的方案，零同步开销 - 若必须全局管理，改用
std::shared_mutex保护（但会显著拖慢吞吐，只适用于低频调用） - 不要试图用
std::seed_seq统一初始化多个线程引擎——它不保证各实例独立性；应为每个线程用不同std::random_device实例或带线程ID的种子
std::random_device 在某些平台不可靠
Linux 上通常读 /dev/urandom，可靠；但 Windows MSVC 的 std::random_device::entropy() 恒为 0，且部分旧版本返回伪随机数。生产环境建议：
- 先检查
rd.entropy() > 0，否则 fallback 到时间+线程ID混合种子 - 避免在循环中反复调用
rd()——它可能有系统调用开销；一次取够 4–8 字节足矣 - 对性能极端敏感场景，可完全弃用
std::random_device，改用std::chrono::high_resolution_clock::now().time_since_epoch().count()加上std::hash<std::thread::id>{}(std::this_thread::get_id())
真正卡住性能的往往不是算法，而是把 std::mt19937 当成无状态函数反复构造、把分布当一次性对象、或者在线程间裸共享引擎——这些错误在压测时才暴露，但修复只需改三行代码。
