std::lock_guard是RAII锁封装类，构造时加锁、析构时解锁，不可复制移动，不支持延迟/尝试锁定；关键在精准控制其作用域以匹配临界区粒度。
std::lock_guard 不是“自动加锁解锁机制”的名字，它就是一个 RAII 封装类，作用是在构造时加锁、析构时解锁——只要生命周期可控，就自然实现了“自动”。关键不是它多智能，而是你得用对它的生命周期。
为什么 std::lock_guard 构造后立刻加锁，析构才解锁
这是 RAII 的核心设计：资源获取即初始化。锁的本质是临界区保护，而临界区的边界必须由作用域精确界定。
-
std::lock_guard构造函数接收一个可锁定对象（如std::mutex），并立即调用其lock()方法 - 它不提供
unlock()接口，也不允许手动干预；析构函数里无条件调用unlock() - 如果构造失败（比如传入已损坏的 mutex），会抛出
std::system_error，此时不会持有锁 - 不能复制，只能移动（C++17 起默认删除拷贝，移动也受限），避免多个 guard 指向同一把锁
常见误用：把 std::lock_guard 声明在函数开头但提前 return
看起来“写了锁”，实际可能根本没覆盖到所有退出路径，或者锁范围过大影响性能。
- 错误写法：
std::lock_guard<:mutex> lg(mtx); do_work(); if (err) return; do_more();——do_more()也被锁住，但逻辑上可能不需要 - 正确做法：用花括号人为缩窄作用域，例如
{ std::lock_guard<:mutex> lg(mtx); risky_access(); } - 更安全的是把受保护逻辑封装进独立函数，让锁的生命期和语义完全对齐
- 别在循环体内反复构造
std::lock_guard，除非每次迭代都确实需要独占访问
和 std::unique_lock 的关键区别在哪
std::lock_guard 是轻量、不可延迟、不可转移的锁包装器；std::unique_lock 更灵活，但也更容易出错。
立即学习“C++免费学习笔记（深入）”；
-
std::lock_guard构造即加锁，不支持延迟锁定（defer_lock）、尝试锁定（try_to_lock）或定时锁定（adopt_lock） - 不能调用
unlock()或lock()，也不能被 move 到另一个作用域（比如返回值） - 如果你需要条件加锁、分阶段加锁、或配合
std::condition_variable，必须用std::unique_lock - 性能上，
std::lock_guard几乎零开销，std::unique_lock多几个字节状态位 + 可能的分支判断
真正容易被忽略的点是：锁的粒度永远比锁的类型重要。用对 std::lock_guard 只是第一步，选错临界区范围、在不该锁的地方锁、或者跨函数传递裸 mutex 指针，都会让 RAII 失效。它不救设计缺陷，只忠实地执行作用域规则。
