std::lock_guard通过raii机制实现自动加锁与解锁：构造时调用lock()，析构时必然调用unlock()，依赖对象作用域生命周期，不靠后台线程或定时器，确保异常安全和死锁规避。
std::lock_guard 析构时自动释放锁
它靠 RAII（资源获取即初始化）机制实现自动释放，不是靠“后台线程”或“定时器”，而是依赖对象生命周期——std::lock_guard 构造时加锁，析构时必然调用 unlock()。只要对象离开作用域（比如函数返回、提前 return、异常抛出），析构函数就会执行。
常见错误是手动调用 unlock() 或试图延长其生命周期：
- 不要在
std::lock_guard对象上显式调用unlock()—— 它没这个 public 成员函数，编译直接报错：error: 'unlock' is not a member of 'std::lock_guard' - 不要把
std::lock_guard存到堆上（比如new std::lock_guard<...>(mtx)</...>），否则析构时机不可控，极易死锁 - 不要把它作为函数返回值或成员变量（除非你明确控制其生存期），它不支持拷贝，移动也受限
为什么不能用 std::lock_guard 做跨作用域锁管理
std::lock_guard 是“作用域锁”，设计初衷就是绑定到局部作用域。它的构造函数会立即调用 mtx.lock()，析构函数固定调用 mtx.unlock()，没有“暂停”“续锁”“移交”能力。
典型误用场景：
- 想在函数里加锁，然后把锁传给另一个函数处理 → 不行，
std::lock_guard无法转移所有权 - 想让锁持续到整个类生命周期 → 错，应改用
std::unique_lock并手动控制，或重构为更小粒度的作用域 - 在 if 分支里声明，但逻辑需要锁覆盖到后续代码 → 锁会在 if 结束时释放，导致后续操作裸奔
std::lock_guard 和 std::unique_lock 的关键区别
两者都遵循 RAII，但 std::unique_lock 更灵活；std::lock_guard 更轻量、更安全、更难误用。
-
std::lock_guard：构造即锁，析构即放，不可延迟锁定（无默认构造），不可转移，不可尝试锁（try_to_lock），不可递归判断 -
std::unique_lock：支持延迟构造（std::defer_lock）、手动lock()/unlock()、try_lock()、owns_lock()查询、可移动、能配合std::condition_variable - 性能上，
std::lock_guard通常略快（少一个布尔状态字段），但差异微乎其微，优先选语义清晰的那个
一个容易被忽略的坑：锁对象和互斥量生命周期不匹配
std::lock_guard 只保存对互斥量的引用，不拥有它。如果互斥量（比如 std::mutex 成员）在 std::lock_guard 还没析构前就被销毁（例如对象析构顺序问题、局部 std::mutex 提前离开作用域），程序会崩溃或 UB。
典型触发点：
- 类中先声明
std::mutex mtx，后声明std::lock_guard<:mutex> guard{mtx}</:mutex>成员 → 析构时先析构guard（安全），再析构mtx（安全） - 反过来：先声明
guard，后声明mtx→guard析构时mtx已销毁，调用unlock()未定义行为 - lambda 捕获了局部
std::mutex，并在异步任务中使用std::lock_guard→ 局部 mutex 已销毁，锁操作失效
RAII 看似简单，但锁的“自动释放”完全依赖正确的对象生命周期安排——稍一错位，就不是没释放，而是释放了个空指针。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
