std::lock_guard通过RAII机制在构造时加锁、析构时自动解锁，依赖对象生命周期管理，无需手动调用unlock()或try-catch，确保异常安全。
std::lock_guard 构造时加锁、析构时解锁的机制是什么
它靠的是 C++ 对象生命周期管理：构造函数里调用 mutex.lock()，析构函数里调用 mutex.unlock()。只要对象在作用域内，就必然持锁；一旦离开作用域（比如函数返回、异常抛出、提前 return），析构自动触发，锁立刻释放。
关键点在于：这个行为不依赖程序员手动写 unlock()，也不依赖 try-catch 包裹——哪怕中间某行代码抛了 std::runtime_error，std::lock_guard 的析构函数仍会执行（前提是没被 noexcept(false) 干扰，但标准库实现已确保其析构是 noexcept）。
为什么不能直接用 std::mutex::lock() / unlock() 手动配对
手动配对在逻辑分支多、有异常可能的场景下极易出错。常见错误包括：
- 忘记写
unlock()（尤其在多个return路径中） - 在
lock()后、unlock()前抛异常，导致锁永远不释放 - 误写成
mutex.unlock()在lock()之前调用，触发未定义行为（UB），常见报错是std::system_error: Operation not permitted - 多线程下重复 unlock 同一个 mutex（例如两个
lock_guard绑定同一实例）会 crash，而手动调用更容易复现这种错误
std::lock_guard 的模板参数和移动语义限制
std::lock_guard 是一个不可复制、不可移动的类模板，声明为 template，实际使用时必须传入具体类型，比如 std::lock_guard<:mutex>。它只支持构造时绑定，不提供 relock() 或 try_lock_for() 等高级操作。
如果你需要超时等待或尝试加锁，得换用 std::unique_lock；如果要保护多个 mutex 避免死锁，要用 std::scoped_lock（C++17）或 std::lock() + std::unique_lock 组合。
示例中常见误写：std::lock_guard<:mutex> guard(m); guard = std::lock_guard<:mutex>(m); —— 这会编译失败，因为赋值运算符被删除。
RAII 成立的前提：mutex 必须是栈上对象且生命周期长于 lock_guard
这是最容易被忽略的一环。如果 std::mutex 本身是局部变量，而 std::lock_guard 在它之后定义，没问题；但如果反过来，或者 mutex 是动态分配（new std::mutex），而 lock_guard 绑定的是它的指针解引用结果，那就要小心析构顺序。
典型陷阱：
- 把
std::mutex成员变量声明在类末尾，而std::lock_guard在构造函数初始化列表中使用它 —— 此时 mutex 尚未构造完成，UB - 返回一个包含
std::lock_guard的结构体，企图“转移锁状态” —— 不可行，lock_guard 没有移动语义 - 在 lambda 中捕获
std::lock_guard并异步执行，lambda 执行时 guard 已析构，锁早被释放
RAII 只保证“对象存在期间锁有效”，不保证“锁有效期间对象还活着”。这点必须靠代码结构来约束。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
