std::lock_guard一构造就加锁、一析构就解锁，因其严格遵循RAII：构造函数调用mutex.lock()，析构函数无条件调用unlock()，不提供手动解锁接口，作用域结束即自动释放，确保异常安全与死锁预防。
std::lock_guard 为什么一构造就加锁、一析构就解锁
因为它的设计就是 RAII 的典型实现：构造函数调用 mutex.lock()，析构函数调用 mutex.unlock()，且不提供手动解锁接口。只要对象在作用域内存在，锁就一直持有；一旦离开作用域（比如函数 return、异常抛出、或块结束），析构自动触发，锁必然释放。
常见错误是试图“提前解锁”——比如写 lg.unlock()，这会编译失败，因为 std::lock_guard 没有 unlock() 成员函数。想手动控制，得换 std::unique_lock。
- 它只支持可拷贝的互斥体（如
std::mutex），不支持std::recursive_mutex的递归特性（除非显式指定模板参数） - 构造时若传入已锁定的 mutex，行为未定义；建议始终用
std::defer_lock配合std::unique_lock做延迟加锁 - 性能上无额外开销：它不维护状态，不分配堆内存，纯栈对象
多线程下保护临界区，怎么写才不出错
核心原则：把 std::lock_guard 声明在临界区最开始、且作用域严格包裹所有共享访问代码。不能把它声明在 if 分支里，也不能放在循环外却想保护循环体内部的共享操作。
错误示例：if (cond) { std::lock_guard<:mutex> lg(mtx); data++; }</:mutex> —— 这样锁只在 if 分支内有效，但 data++ 可能被其他线程并发修改。
立即学习“C++免费学习笔记（深入）”；
- 正确做法是把锁声明在临界区入口处，且作用域覆盖全部读/写共享变量的语句
- 如果临界区跨多个函数调用，把锁对象作为参数传入不安全；应把锁逻辑留在调用方，或改用
std::unique_lock并转移所有权 - 避免在锁内调用可能阻塞或抛异常的函数（如 IO、new、第三方库回调），否则延长持锁时间或导致死锁
std::lock_guard 和 std::unique_lock 能不能混用同一个 mutex
可以，但必须确保不重叠持有。比如一个线程用 std::lock_guard 持有锁期间，另一个线程不能再用 std::unique_lock 尝试 lock 同一个 mtx，否则会阻塞或失败（取决于是否带 try_to_lock）。
真正危险的是“双重加锁”：同一线程中，对同一个 std::mutex 实例连续构造两个 std::lock_guard，第二个构造会死锁（因为 mutex 不可重入）。
-
std::mutex不是递归的，std::recursive_mutex才支持同一线程多次加锁 -
std::lock_guard构造时若传入std::defer_lock，它不会加锁，但此时它也不再符合 RAII 的“自动管理”语义，别这么用 - 跨函数传递锁状态？别传
std::lock_guard，它不可移动不可拷贝；要用std::unique_lock+std::move()
调试时发现程序卡在 lock()，怎么定位
卡在 std::mutex::lock() 通常意味着该 mutex 正被另一个线程持有，且迟迟未释放。这不是 std::lock_guard 的问题，而是锁的使用逻辑或持有时间过长。
优先检查三件事：是否有线程忘记用 std::lock_guard（比如裸调 mtx.lock() 后没配 mtx.unlock()）；是否在锁内做了耗时操作（如 sleep、网络请求）；是否存在锁顺序不一致导致的死锁（A 锁 M1 再 M2，B 锁 M2 再 M1）。
- 用
std::timed_mutex替换std::mutex，配合std::try_to_lock，可在超时后打印上下文并 abort，辅助定位 - Linux 下可用
pstack或gdb attach查看各线程当前调用栈，确认谁持有了哪个 mutex - 不要依赖析构函数里的日志来判断锁是否释放——异常可能打断执行流，日志不一定输出
