std::uniform_int_distribution 的 min() 和 max() 返回闭区间端点，即生成值满足 d.min() ≤ d(gen) ≤ d.max()，包含上下界。
为什么 std::mt19937 每次生成的序列都一样？
因为没正确设置种子，std::mt19937 默认构造会用固定值（通常是 5489）初始化，导致每次运行程序都产出完全相同的随机数流。这不是 bug，是设计使然——可复现性对测试和调试至关重要。
实操建议：
- 生产环境用
std::random_device获取真熵：std::mt19937 gen{std::random_device{}()}; - 单元测试中需复现时，显式传入固定种子：
std::mt19937 gen{42}; - 避免在循环内反复构造引擎（如
for(...) { mt19937 g{rd()}; ... }），这会耗尽熵源且性能极差
std::uniform_int_distribution 的 min()/max() 是闭区间还是开区间？
闭区间 —— 即 d(gen) 返回值满足 d.min() 。这是 C++11 标准明确规定的，和 Python 的 <code>random.randint 一致，但不同于 numpy.random.randint（后者右边界默认开）。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 误写成
uniform_int_distribution<int>(1, 6)</int>以为只生成 1~5，结果 6 也会出现 - 跨平台移植时，若依赖旧版 libstdc++（GCC min()==max() 时返回异常值，现已修复
- 不要重复创建分布对象：它无状态，但构造有开销；应复用同一个
uniform_int_distribution实例
如何安全共享一个随机引擎实例而不破坏线程安全性？
std::mt19937 本身不是线程安全的：多个线程同时调用 operator() 会破坏内部状态。但你不需要锁住整个引擎来换取并发吞吐。
推荐策略：
- 每个线程独占一个引擎实例（最简单、零同步开销）：用
thread_local std::mt19937 gen{std::random_device{}()}; - 若必须全局共享（如日志采样率控制），用
std::atomic+ 轻量级 CAS 更新种子不现实，改用std::mutex保护单次gen()调用 —— 但注意这会成为热点瓶颈 - 避免把引擎塞进单例或全局变量再裸指针传递，容易引发静态初始化顺序问题（SIOF）
生成百万级随机整数时，std::mt19937_64 比 std::mt19937 快多少？
在 x86-64 上，std::mt19937_64 单次 operator() 平均比 std::mt19937 快 10%~15%，主要因原生 64 位运算减少指令数；但实际差异常被分布对象和内存访问掩盖。
关键权衡点：
- 若只需 32 位整数（如索引、枚举），用
mt19937节省内存（状态大小 2.5KB vs 5KB），L1 缓存更友好 -
mt19937_64的周期是 2^19937−1，和mt19937同量级，**不是**“更随机”，只是状态向量更大 - 某些嵌入式平台或 WASM 环境可能不支持
mt19937_64，编译期可用__cpp_lib_random_device宏检测
真正影响吞吐的，往往是分布对象的模板实例化方式和是否启用 -O3 -march=native，而不是引擎选型本身。
