应按固定全局顺序加锁或用std::scoped_lock避免死锁；90%场景用std::lock_guard，仅需延迟加锁/条件变量时选std::unique_lock；静态局部mutex在c++11后线程安全但需注意编译器支持；跨平台行为一致但调试表现不同。
std::mutex 怎么加锁才不会死锁
加锁顺序不一致是死锁最常见原因，std::mutex 本身不提供嵌套或超时机制，一旦 lock() 被阻塞，线程就卡住不动。
- 永远按固定全局顺序获取多个 mutex：比如所有模块都先锁
g_user_mutex，再锁g_config_mutex，反过来就是隐患 - 用
std::lock()同时锁定多个 mutex，它内部会重排顺序避免死锁：std::lock(mutex_a, mutex_b) - 优先用
std::scoped_lock（C++17）替代std::lock_guard，它原生支持多 mutex 且自动规避死锁：std::scoped_lock lk(mutex_a, mutex_b) - 别在持有 mutex 期间调用可能间接再拿锁的函数（比如日志、回调、第三方库接口）
std::lock_guard 和 std::unique_lock 到底选哪个
std::lock_guard 是轻量封装，构造即加锁、析构即释放，不可转移、不可延迟；std::unique_lock 更灵活，但开销略大，别为“看起来更高级”而滥用。
- 90% 场景用
std::lock_guard就够了：std::lock_guard<:mutex> lk(mtx)</:mutex> - 需要手动控制加锁时机（比如先声明后
lk.lock()）、条件等待（配合std::condition_variable）、或要转移锁所有权时，才用std::unique_lock -
std::unique_lock默认构造时不加锁，容易误以为“已经安全”，漏掉lk.lock()导致数据竞争 - 不要把
std::unique_lock当成std::lock_guard的升级版来无脑替换
为什么局部 static mutex 有时会崩溃
静态局部变量的初始化不是线程安全的（C++11 前），即使你写了 static std::mutex mtx，首次访问时仍可能触发多线程同时初始化 mutex 对象本身。
- C++11 起，静态局部变量的初始化已保证线程安全，但前提是编译器和标准库完整支持——老版本 GCC 或 MinGW 可能有缺陷
- 更稳妥的做法是用函数作用域的 static 指针 +
std::call_once：static std::mutex* get_global_mutex() { static std::once_flag flag; static std::mutex* p = nullptr; std::call_once(flag, []{ p = new std::mutex; }); return p; } - 避免在 DLL 或共享库中依赖局部 static mutex，加载/卸载时机复杂，容易引发析构顺序问题
std::mutex 在 Windows 和 Linux 下行为一致吗
接口一致，底层实现不同，但对用户透明；真正影响行为的是调度策略、争用表现和调试支持，不是 mutex 语义本身。
立即学习“C++免费学习笔记（深入）”；
-
std::mutex在所有主流平台都是非递归锁：同一线程重复lock()会死锁，不是抛异常 - Windows 上默认使用 CRITICAL_SECTION（轻量），Linux 用 pthread_mutex_t（可配置类型），但 C++ 标准规定行为必须一致
- 调试时注意：MSVC 的 Debug 版 runtime 会对
std::mutex做额外检查（比如 double unlock 报 assertion），而 GCC/Clang 通常不报——别因此误判“Linux 更宽松” - 别依赖未定义行为，比如读取已销毁 mutex 的状态，或者跨线程传递未加锁的
std::mutex对象
mutex 看似简单，真正的坑都在边界上：初始化顺序、锁粒度选择、跨平台构建配置、以及——最容易被忽略的——你根本没意识到某个函数内部悄悄用了全局状态。
