rand() 已被 c++11 标准弃用，因其随机性差、线程不安全、跨平台不可移植；应改用 中的引擎（如 std::mt19937）与分布组合，并正确初始化种子（优先 std::random_device， fallback 到时钟），多线程需独立引擎实例。
为什么 rand() 不该再用了
因为不随机、不可控、难移植。rand() 用的是线性同余法，低比特位周期短，rand() % N 会严重偏向小值；它只有一个全局状态，多线程下直接崩；C++11 之后标准明确建议弃用。别被老教程带偏，现在写新代码还用 rand() 就是给自己埋坑。
常见错误现象：rand() % 10 生成的“0–9”分布明显不均，尤其在循环次数少时；多线程调用后结果重复或崩溃；跨平台编译（比如 macos vs linux）输出序列不同。
- 改用
<random></random>头文件里的引擎 + 分布组合 - 不要复用同一个
std::mt19937实例在多个线程里 - 种子别硬写
12345，用std::random_device获取真随机熵（若不可用，退到std::chrono::steady_clock）
std::mt19937 怎么配种子才靠谱
种子决定整个随机序列起点，配错就白搭。直接传 1 或时间戳秒数（time(nullptr)）会导致每次重启程序都生成同一串数——对测试像样，对实际逻辑是灾难。
使用场景：需要每次运行都不同序列（如游戏初始化、模拟实验），又不能依赖外部输入。
立即学习“C++免费学习笔记（深入）”；
- 首选
std::random_device{}()，它尝试访问系统熵源（Linux /dev/urandom，windows CryptGenRandom） - 如果
std::random_device{}.entropy() == 0.0，说明是伪实现（某些 MinGW 或嵌入式环境），此时改用std::chrono::steady_clock::now().time_since_epoch().count() - 别把种子存成
int——std::mt19937接受std::uint32_t，但种子可能超范围；用std::seed_seq更安全
整数、浮点、布尔——怎么选对分布类型
引擎只管生成均匀的 32/64 位整数，具体范围和类型全靠分布类转换。选错分布不仅结果不对，还可能悄悄截断或溢出。
参数差异：
- 要 [1, 6] 的骰子？用
std::uniform_int_distribution<int>{1, 6}</int>—— 注意是闭区间，两个参数都包含 - 要 [0.0, 1.0) 的浮点？用
std::uniform_real_distribution<double>{0.0, 1.0}</double>—— 这是左闭右开，1.0永远不会出现 - 要抛硬币？
std::bernoulli_distribution{0.5}比dist(mt) % 2更语义清晰，且避免整数分布的隐式转换陷阱
性能影响：分布对象轻量，可复用；但别在循环里反复构造分布实例（比如每次生成一个数都 new 一个 uniform_int_distribution），它内部有预计算。
多线程下怎么避免数据竞争
std::mt19937 非线程安全，引擎状态在 operator()() 调用中修改。多个线程共用一个实例，结果不可预测，还可能破坏内部状态。
常见错误现象：生成的数突然变成全 0、重复大段序列、程序偶发崩溃（尤其在调试器里更明显）。
- 每个线程持有一个独立的引擎实例（推荐）：用
thread_local std::mt19937，配合本地种子 - 或者用锁包裹调用（不推荐）：加锁开销大，且违背随机数生成的低延迟初衷
- 注意
std::random_device本身是线程安全的，但它的构造和调用频率不宜过高（有些实现会耗尽熵池）
真正容易被忽略的是：即使你用了 thread_local，如果所有线程都用相同种子（比如都用 std::random_device{}()），仍可能因熵源不足导致初始状态雷同——这时得给每个线程加一点区分度，比如混入线程 ID 或地址哈希。