因为默认构造的std::mt19937使用固定种子0，导致每次运行生成相同序列；生产环境应使用std::random_device供熵，单元测试则用固定种子（如42）确保可复现。
为什么 std::mt19937 每次跑结果都一样？种子没重置
不是引擎坏了，是默认构造的 std::mt19937 用的是固定种子（0），所有实例行为完全一致。真实场景中必须显式提供种子，否则单元测试通过、线上却复现不了问题。
常见错误写法：std::mt19937 gen; —— 这等价于 std::mt19937 gen{0};，永远生成同一串数。
推荐做法：
- 测试/调试时用固定种子（如
42）确保可复现：std::mt19937 gen{42}; - 生产环境用
std::random_device获取熵源：std::random_device rd; std::mt19937 gen{rd()}; - 若需多线程安全，每个线程独占一个
gen实例，不要共享；std::random_device本身线程安全，但调用频率过高可能耗尽系统熵池
std::uniform_int_distribution 的模板参数到底填什么？
它不接受运行时类型，只认编译期整型类型。填错会导致静默截断或编译失败。
立即学习“C++免费学习笔记（深入）”；
比如想生成 [0, 999] 范围的 int32_t，不能写 uniform_int_distribution<int>(0, 999)</int> 然后赋给 int32_t 变量——看似能跑，但若平台 int 是 16 位，就溢出了。
正确写法必须严格匹配目标变量类型：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 生成
int32_t：std::uniform_int_distribution<int32_t>{0, 999}</int32_t> - 生成
uint64_t：std::uniform_int_distribution<uint64_t>{1, UINT64_MAX}</uint64_t> - 范围上下界必须能隐式转换为目标类型，否则编译报错：
std::uniform_int_distribution<int8_t>{0, 300}</int8_t>会失败（300 > INT8_MAX）
高性能场景下，为什么别在循环里反复构造 std::uniform_int_distribution？
分布对象本身不含状态，构造开销虽小但可避免。更关键的是：某些标准库实现（如 libstdc++）在构造时会做预计算（比如对除数取倒数），频繁构造等于反复做无用功。
实测在密集生成循环中，把分布对象提到循环外，可提升 5%–12% 吞吐（取决于编译器和分布范围）。
错误示范：
for (int i = 0; i < N; ++i) {
std::uniform_int_distribution<int> dist(0, 100);
result[i] = dist(gen);
}正确写法：
std::uniform_int_distribution<int> dist(0, 100);
for (int i = 0; i < N; ++i) {
result[i] = dist(gen);
}如何安全地序列化/反序列化 std::mt19937 状态？
标准库没提供直接的二进制 dump 接口，但支持通过 operator 和 <code>operator>> 流式读写内部状态。这是唯一便携方式，比手撕数组或依赖私有成员可靠得多。
注意点：
- 流操作符读写的不是“种子”，而是整个引擎当前完整状态（19937 引擎共 624 个 uint32_t）
- 必须用同一标准库实现版本读写，跨 GCC/Clang 或不同 STL 版本可能不兼容
- 写入前确保流处于 good 状态，读取后检查
if (!is) { /* 失败 */ } - 示例存档：
std::ofstream os("state.bin", std::ios::binary); os - 示例恢复：
std::ifstream is("state.bin", std::ios::binary); is >> gen;
别试图用 gen.seed() 加载旧状态——那只是重新初始化，不是恢复。
