std::lock_guard能自动解锁是因为其采用RAII机制：构造时加锁，析构时（无论是否异常）必调用unlock()，确保作用域结束即释放锁，避免死锁；它不可拷贝移动、不支持延迟加锁，仅适用于作用域内独占锁定。
std::lock_guard 为什么能自动解锁
它本质是个 RAII 封装：构造时加锁，析构时（无论是否异常）必调用 unlock()。不用手动配对 lock()/unlock()，避免忘记解锁或异常跳过解锁导致死锁。
常见错误现象：std::mutex 被重复 lock()（未解锁就再锁）→ 抛出 std::system_error（错误码为 resource_deadlock_would_occur）；或忘记解锁 → 后续线程永久阻塞。
- 只适用于「作用域内独占锁定」场景，比如临界区代码块、函数局部保护
- 不能转移所有权，不支持拷贝/移动，生命周期必须严格绑定作用域
- 构造时若传入
std::defer_lock标签，则不加锁，需后续手动lock()—— 这时已脱离lock_guard的自动管理本意，慎用
std::lock_guard 的正确初始化方式
必须在定义时直接构造，且传入一个可访问的 std::mutex（或其派生类如 std::recursive_mutex）左值引用。不能先声明再赋值，也不能用临时 mutex。
错误写法：std::lock_guard<std::mutex> guard; guard = std::lock_guard<std::mutex>(mtx); → 编译失败（lock_guard 不可赋值）
立即学习“C++免费学习笔记（深入）”；
正确写法示例：
std::mutex mtx;
void safe_increment() {
std::lock_guard<std::mutex> guard(mtx); // ✅ 构造即加锁
counter++;
} // ✅ 离开作用域自动 unlock()
- 模板参数必须与 mutex 类型严格匹配，
std::lock_guard<std::recursive_mutex>不能用于普通std::mutex - 不要把
lock_guard定义在函数开头却在中间 return —— 虽然仍会析构，但语义上容易误判临界区范围 - 若需延迟加锁（如尝试锁），该用
std::unique_lock+try_lock()，不是lock_guard的职责
和 std::unique_lock 的关键区别在哪
lock_guard 是轻量、不可变、仅 RAII 的锁包装；unique_lock 是功能完整、可转移、支持延迟/尝试/递归操作的锁管理器。性能上 lock_guard 构造/析构开销略小，但差异微乎其微。
典型误用场景：想在 if 分支里有条件加锁，或需要把锁对象传出函数 —— 这些都超出 lock_guard 能力边界。
-
lock_guard没有unlock()或lock()成员函数，无法手动干预锁状态 -
unique_lock可以release()交出 mutex 控制权；lock_guard一旦构造，生命周期内锁状态完全固定 - 多互斥量加锁（如
std::lock(a, b)）后，必须用unique_lock包装才能传递给lock_guard—— 实际上此时应直接用std::scoped_lock（C++17）
std::scoped_lock 替代 lock_guard 的时机
C++17 引入 scoped_lock，是 lock_guard 的超集：支持同时锁定多个互斥量，且自动规避死锁（按地址顺序加锁）。单 mutex 场景下，它和 lock_guard 行为一致，但更现代、更安全。
如果你的项目已支持 C++17，新代码优先用 scoped_lock；老代码维护中遇到多 mutex 场景，别硬凑多个 lock_guard —— 那样不保证加锁顺序，极易引发死锁。
-
std::scoped_lock<std::mutex, std::mutex> guard(mtx1, mtx2);✅ 安全锁定两个互斥量 -
std::lock_guard<std::mutex> g1(mtx1), g2(mtx2);❌ 无序加锁，竞态风险高 -
scoped_lock也不支持转移或手动解锁，语义仍是“作用域绑定 + 自动释放”，只是能力更强
真正容易被忽略的是：哪怕只锁一个 mutex，scoped_lock 的类型推导和构造行为也比 lock_guard 更一致，尤其配合模板或 auto 时不易出错。
