应使用std::uniform_int_distribution配合std::mt19937生成[a,b]闭区间整数，避免rand()%N或gen()%N导致的模偏差；引擎需用std::random_device等可靠熵源初始化，线程局部存储，分布对象可复用。
std::mt19937 配合 uniform_int_distribution 生成整数，别手写 % 运算
直接用 gen() % N 生成 [0, N) 范围整数是高频错误，会导致分布偏差——尤其当 N 与 gen.max()（通常是 2³²−1）不可整除时，小余数部分的数会少出现一次。比如 mt19937 生成 0–4294967295，对 100 取模，0–95 各出现 42949673 次，96–99 只有 42949672 次。
正确做法是交由标准分布器处理：
-
std::uniform_int_distribution<int> dist(a, b)</int>保证闭区间 [a, b] 内每个整数概率严格相等 - 分布对象轻量，可复用；不要在循环里反复构造它
- 若需生成
size_t或大范围整数（如 ≥2³¹），优先用std::mt19937_64+std::uniform_int_distribution<size_t></size_t>，避免两次调用拼接
种子初始化必须避开 time(nullptr)，否则高并发下序列雷同
std::mt19937 gen(time(nullptr)) 在秒级分辨率下极易撞 seed：同一秒启动的多个进程、单元测试快速重跑、容器内密集拉起服务，都会拿到相同初始状态，输出完全一致的随机序列。
可靠方案是组合熵源，且只初始化一次：
立即学习“C++免费学习笔记（深入）”；
- 首选
std::random_device rd，但注意它在 MinGW 或某些容器中可能退化为确定性伪随机（rd.entropy() == 0） - fallback 方案：用
std::chrono::high_resolution_clock::now().time_since_epoch().count()提供纳秒级时间戳 - 再混入地址哈希或 TSC（
__rdtsc()）提升不可预测性，例如：seed ^= reinterpret_cast<uintptr_t>(&gen)</uintptr_t>
多线程场景下，每个线程必须持有独立 mt19937 实例
std::mt19937 不是线程安全的；共享单个实例并行调用 operator()() 会导致状态竞争，结果未定义。更糟的是，有人试图加锁保护，这会严重拖慢吞吐——随机数本该是无锁热点路径。
正确做法是线程局部初始化：
- 用
thread_local std::mt19937 gen([]{ /* 可靠种子逻辑 */ }())，C++17 起支持带捕获的 lambda 初始化 - 或在线程入口处手动构造，确保种子来源互不相关（避免所有线程都用同一个
std::random_device实例） - 切勿把
gen声明为全局 static 并期望“一次初始化、处处可用”——静态初始化顺序和线程可见性都不可靠
mt19937 和 mt19937_64 性能差异被严重高估，选错反而拖慢缓存
多数人以为 “64 位一定更快/更强”，实际在典型整数采样场景（如数组索引、骰子、ID 生成）中，std::mt19937 更优：
-
mt19937单次调用约 4ns，mt19937_64约 6–8ns，差异来自更大状态更新开销 -
mt19937的 19937-bit 状态全部适配 L1 缓存（通常 ≤32KB），而mt19937_64状态翻倍，L1 miss 概率上升 - 只有当你明确需要
uint64_t输出、或模拟 64 位哈希碰撞等特殊场景，才值得切换
真正影响性能的不是引擎选型，而是分布器复用方式和种子初始化质量——这两点出错，换再快的引擎也救不回重复序列或偏差分布。
