std::lock_guard仅确保单个互斥量的RAII式自动加锁/解锁，不防死锁；多锁需用std::scoped_lock或std::lock+defer_lock组合，且须统一锁顺序、缩小临界区。
std::lock_guard 本身不防止死锁，它只保证单个互斥量的自动释放
很多人误以为 std::lock_guard 能“防死锁”，其实它连死锁检测或规避逻辑都没有。它的唯一职责是 RAII 式地管理一个 std::mutex 的生命周期：构造时加锁，析构时解锁。如果线程在持有一个锁的同时，又去尝试获取另一个**已被其他线程持有且顺序不一致**的锁，std::lock_guard 完全无能为力。
真正影响死锁风险的是锁的获取顺序和粒度，而不是用不用 lock_guard。
多锁场景下必须用 std::scoped_lock（C++17）或 std::lock + lock_guard 组合
当你需要同时锁定多个互斥量（比如操作两个共享对象），手动按固定顺序加锁容易出错；一旦两个线程以相反顺序调用 lock_guard(mutex_a) 和 lock_guard(mutex_b)，就极易触发死锁。
正确做法是让标准库帮你一次性、原子性地获取所有锁：
立即学习“C++免费学习笔记（深入）”；
- C++17 起，直接用
std::scoped_lock：它内部调用std::lock，保证所有互斥量被同时锁定，且避免了死锁可能（通过试探性加锁+回退机制） - 旧标准（C++11/14）可用
std::lock(mutex_a, mutex_b)配合std::lock_guard的带std::defer_lock构造函数
示例（C++17）：
std::mutex mtx_a, mtx_b; // ✅ 安全：不会因加锁顺序导致死锁 std::scoped_lock lock(mtx_a, mtx_b); // 原子获取两个锁 // ... 访问共享资源 // 自动解锁，无需手动干预
std::lock_guard 不支持递归锁，也不支持延迟/手动加锁
如果你不小心在同一线程中对同一个 std::mutex 多次构造 std::lock_guard，会导致未定义行为（通常是程序挂起或崩溃）。这是因为 std::mutex 默认是非递归的。
常见错误场景：
- 函数 A 持有
std::lock_guard<:mutex></:mutex>并调用函数 B，而 B 内部又尝试锁同一个 mutex - 误以为
std::lock_guard支持try_lock或可重入 —— 它不支持，该用std::unique_lock
若需递归访问或条件加锁，请换用 std::unique_lock<:recursive_mutex></:recursive_mutex> 或 std::unique_lock<:mutex></:mutex>。
性能与兼容性注意点：不要在锁内做耗时操作，也不要跨作用域传递 lock_guard
std::lock_guard 是轻量级栈对象，构造/析构开销极小，但它的生命周期决定了锁的持有时间 —— 锁住太久会严重拖慢并发性能。
典型陷阱：
- 把
std::lock_guard声明在函数开头，但后面做了日志打印、网络调用、文件读写等耗时操作 - 试图把
std::lock_guard对象返回、存储到容器、或传给 lambda 捕获 —— 它不可复制、不可转移，这么做编译不过 - 在异常路径中依赖其自动析构没问题，但若你 catch 异常后继续用已保护的数据，要确认锁是否仍有效（它始终有效到作用域结束）
锁的范围应该严格限制在真正访问共享数据的几行代码内，其余逻辑移出临界区。
死锁从来不是锁没用对，而是资源获取顺序没约定好，或者临界区设计得过大。用对 std::scoped_lock 和控制好锁粒度，比纠结 std::lock_guard 的用法重要得多。
