std::lock_guard是锁的生命周期管理者，仅在作用域开始时加锁、结束时自动解锁，核心价值是防止忘记解锁、异常或提前return导致死锁。
std::lock_guard 在 C++ 多线程里到底干啥用？
它不是“加锁工具”，而是“锁的生命周期管理者”——只在作用域开始时调用 mutex.lock()，作用域结束时自动调用 mutex.unlock()。核心价值不是简化加锁动作，而是防止忘记解锁、提前 return 或异常导致死锁。
- 锁必须是可移动（moveable）但不可复制（non-copyable）的类型，比如
std::mutex、std::recursive_mutex - 不能用在
std::shared_mutex上（它不提供lock()/unlock()原始接口，得用std::shared_lock或std::unique_lock） - 构造时若传入
std::defer_lock，不会立即加锁；但这时你已经绕过了lock_guard的设计初衷，不如直接用std::unique_lock
std::lock_guard 构造失败会怎样？
它本身不抛异常，但底层 mutex.lock() 可能抛 std::system_error（比如递归锁被重复 lock，或互斥量状态损坏）。注意：这不是 lock_guard 的错，是锁本身的约束被违反了。
-
std::mutex对重复 lock 行为是未定义行为（UB），某些平台 crash，某些静默卡死 -
std::recursive_mutex允许同一线程多次 lock，但必须配对 unlock，lock_guard仍只管一次析构 unlock - 如果你在构造
std::lock_guard前已经持有了该 mutex，后续构造会 UB —— 没有运行时检查，编译器也不会警告
为什么不能把 std::lock_guard 当成函数参数传进去？
因为它是 move-only 类型，且禁止拷贝。常见误写：
void f(std::lock_guard<std::mutex> lg) { ... } // ❌ 编译失败：copy constructor deleted更隐蔽的问题是“提前释放”：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
{
std::lock_guard<std::mutex> lg(mtx);
f(); // 若 f() 里又用了 mtx，就可能冲突
}-
lock_guard的生命期严格绑定到其声明的作用域大括号 - 它不提供
release()或owns_lock()接口（那是std::unique_lock的事） - 想跨作用域传递锁管理权？用
std::unique_lock，但得清楚自己在承担手动管理风险
std::lock_guard 和 std::unique_lock 能混用同一个 mutex 吗？
能，但危险。两者都依赖同一 mutex 对象的内部状态，而 lock_guard 不检查当前是否已 lock，unique_lock 也不知外面有没有人用 lock_guard 正管着它。
- 同一时刻，只能有一个 owner 调用
unlock()；否则第二次 unlock 是 UB - 如果你用
lock_guard包住一段代码，中间又用unique_lock去 try_lock 同一个 mutex，结果取决于调度和时序，极易出竞态 - 真需要灵活控制（延迟加锁、条件等待、转移所有权），统一用
std::unique_lock；若只是“进作用域就锁、出就放”，lock_guard更轻量、意图更清晰
C++ 标准库没做运行时锁状态跟踪，所有“谁在管这个 mutex”的责任都在程序员手里。写的时候顺手加个 lock_guard 很容易，但一旦涉及异常路径、多层嵌套或跨函数协作，漏掉一个 unlock 或多套一层 guard，问题就藏得又深又晚。
