std::lock_guard仅适用于构造即加锁、作用域结束即解锁的简单场景；它不支持延迟加锁、try_lock、超时或手动解锁，且多锁需配合std::lock与std::adopt_lock避免死锁。
std::lock_guard 是最直接、最安全的 RAII 互斥锁管理方式，但它只适合“构造即加锁、作用域结束即解锁”这种简单场景；用错类型、漏写参数或误放作用域，反而比手动 lock/unlock 更危险。
std::lock_guard 构造时就加锁，不支持延迟或手动干预
它没有 try_lock()、unlock() 或超时机制，只要声明了 std::lock_guard<:mutex></:mutex>，构造函数立刻调用 mtx.lock()。失败就抛 std::system_error，无法捕获后重试或跳过。
- 临界区必须短小——别在函数开头声明一个
std::lock_guard，然后让它活到函数末尾，中间还夹着 I/O 或复杂计算 - 需要条件判断后再决定是否加锁？不行，
std::lock_guard的构造不可跳过 - 想先
try_lock()成功再进临界区？换std::unique_lock，它支持try_lock()和手动unlock()
多个 mutex 加锁必须用 std::lock + std::adopt_lock
对两个 std::mutex 各自构造 std::lock_guard，极易死锁：线程 A 拿 mtx_a 等 mtx_b，线程 B 拿 mtx_b 等 mtx_a。
- 正确做法是先调用
std::lock(mtx_a, mtx_b)原子性获取全部锁，再用std::lock_guard管理生命周期 -
std::lock_guard构造时第二个参数必须是std::adopt_lock，否则它会再次调用mtx_a.lock()→ 未定义行为 -
std::lock的防死锁机制依赖参数顺序一致：所有线程都按相同地址顺序传参（比如&mtx_a ），否则仍可能死锁
不能用于 std::shared_mutex 或 std::timed_mutex
std::lock_guard 只接受带单一 lock()/unlock() 接口的互斥类型，例如 std::mutex、std::recursive_mutex。
-
std::shared_mutex提供lock_shared()和lock()，没有统一lock()→std::lock_guard<:shared_mutex></:shared_mutex>编译失败 -
std::timed_mutex支持超时，但std::lock_guard不提供超时构造接口 → 必须用std::unique_lock - C++17 起推荐用
std::scoped_lock替代std::lock + std::lock_guard组合，更简洁且自带死锁防护
std::lock_guard 不可拷贝、不可移动、不能作类成员
它的设计目标就是栈上独占、作用域绑定。一旦离开作用域，析构自动 unlock；任何试图转移所有权的行为都会编译失败。
- 不能作为类成员变量存储——因为对象生命周期远长于单次临界区，且无法控制何时加锁
- 不能传参或返回——没有拷贝/移动构造函数，
std::lock_guard是 deleted 的 - 不能复用：同一个对象不能多次用于不同临界区，每次都需要新声明
真正容易被忽略的是：RAII 不是银弹，std::lock_guard 的“自动”背后有严格前提——你得确保它只出现在真正需要加锁的最小作用域里，且所有锁的获取顺序全局一致。一旦跨作用域、跨线程、跨类型混用，问题不会当场报错，而是在高并发下间歇性卡死或数据错乱。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
