std::mt19937 本身不生成高质量随机数，仅执行确定性状态转移；高质量依赖种子来源、分布器选择、复用方式和线程隔离——缺一不可。
直接说结论：std::mt19937 本身不“生成高质量随机数”，它只做一件事：对给定种子执行确定性状态转移，输出高质量的伪随机比特流；真正决定“高质量”的，是种子来源、分布器选择、复用方式和线程隔离策略——漏掉任一环，std::mt19937 就只是个周期长但结果可预测的数学黑箱。
为什么 std::mt19937 构造后不能直接用 gen() 得到好随机数
std::mt19937 输出的是 32 位无符号整数（uint32_t），值域为 [0, 2³²)，但这些原始值不是你想要的“1~6 的骰子”或“[0.0, 1.0) 的浮点数”。直接调用 gen() 返回的是引擎内部状态的映射，未经分布校准，无法保证目标区间均匀性，更无法控制开闭语义。
- 常见错误：写成
int x = gen() % 6 + 1;—— 这会重蹈rand()覆辙，引入数学偏差（因为 2³² 不能被 6 整除） - 正确做法：必须配合
std::uniform_int_distribution<int></int>或std::uniform_real_distribution<double></double>等分布器，由它们负责拒绝采样或精确归一化 - 注意：
std::uniform_int_distribution参数是闭区间（如dist(1, 6)表示结果 ∈ {1,2,3,4,5,6}），而std::uniform_real_distribution默认是左闭右开（dist(0.0, 1.0)永远不会返回 1.0）
std::random_device 初始化种子时的三个致命陷阱
std::random_device 是目前最便携的熵源，但它不是“万能钥匙”，在不同平台和上下文中行为差异极大。
- Windows MSVC 旧版本中，
std::random_device可能 fallback 到时间戳，rd.entropy()返回 0 —— 此时直接用于构造std::mt19937会导致所有线程拿到相同种子 - 在全局/静态对象中写
std::mt19937 gen{std::random_device{}()}，可能触发静态初始化顺序问题（std::random_device构造依赖未就绪的系统服务） - 频繁构造
std::random_device（比如每次函数调用都std::random_device{}()）可能耗尽熵池或引发重复调用开销 - 推荐做法：单例式提取，例如用
std::array<uint32_t></uint32_t>填充后喂给std::seed_seq，再初始化引擎
多线程下 std::mt19937 必须 thread_local，不能加锁共享
std::mt19937::operator() 不是原子操作，其内部状态更新涉及多个数组元素读写。若多个线程共用一个实例并加互斥锁，性能会断崖下跌（实测吞吐量下降 5–10 倍），且仍可能因编译器重排或缓存不一致导致越界或重复序列。
立即学习“C++免费学习笔记（深入）”；
- 错误模式：全局
std::mt19937+std::mutex包裹dist(gen) - 正确模式：声明为
thread_local static std::mt19937 gen{...}，每个线程独享实例，零同步开销 - 注意：
thread_local静态变量的初始化只在该线程首次进入作用域时发生，因此std::random_device也只调用一次，避免熵耗尽 - 若需跨线程复现某次运行的全部随机流（如调试仿真回放），应把种子值显式记录并传入每个线程的引擎构造中，而非依赖
std::random_device
std::uniform_int_distribution 构造和调用的性能敏感点
这个分布对象轻量，但构造和调用仍有隐含成本，高频场景下极易成为瓶颈。
- 禁止在循环内写
std::uniform_int_distribution<int>(1, 6)(gen)</int>—— 每次都新建对象，触发模板实例化、范围校验和除法运算 - 推荐声明为
static const std::uniform_int_distribution<int> dist(1, 6)</int>或thread_local static成员，复用同一实例 - 若上下界是运行时变量（如用户输入的
a,b），不要反复构造新分布，改用dist.param({a, b})动态更新参数（C++11 起支持） - 切忌混用类型：写
std::uniform_int_distribution<int>(1LL, 6LL)</int>可能意外匹配long long特化版本，导致编译失败或行为异常；边界字面量应与模板参数类型严格一致
最容易被忽略的一点：分布器的质量不来自引擎，而来自你是否让它“安静地工作”——它需要稳定的引擎实例、正确的区间语义、线程隔离的执行环境，以及一次到位的初始化。任何临时构造、类型模糊、跨线程共享或手动缩放，都在绕过标准库为你精心设计的无偏保障机制。
