std::scoped_lock 能自动避免死锁，但必须一次性锁定所有互斥量
死锁常发生在多个线程以不同顺序调用 std::lock_guard 锁定多个 std::mutex 时。比如线程 A 先锁 mtx1 再锁 mtx2，线程 B 反过来先锁 mtx2 再锁 mtx1 —— 这种场景下 std::lock_guard 完全无法预防死锁，它只负责单个互斥量的 RAII 管理。
std::scoped_lock 的核心价值是：在构造时对传入的所有互斥量调用 std::lock（底层使用死锁避免算法，如尝试加锁 + 退避重试），确保要么全部成功，要么一个都不上锁。这从源头切断了“部分加锁、等待对方释放”的死锁路径。
常见错误是把它当 std::lock_guard 的多参数替代品，却分多次构造：
// ❌ 错误：两次独立构造，仍可能死锁 std::scoped_lock l1(mtx1); std::scoped_lock l2(mtx2); // 此时 mtx2 可能已被别的线程持有了，而 mtx1 已锁住 // ✅ 正确：一次性声明所有要锁的互斥量 std::scoped_lock l(mtx1, mtx2); // 原子性获取两个锁
- 必须把所有需要的
std::mutex（或支持lock()/try_lock()/unlock()的类型）一次性传给std::scoped_lock构造函数 - 不支持运行时动态决定锁哪些互斥量（比如根据条件选锁 1 个或 2 个），这种需求得回退到
std::lock+ 手动std::lock_guard - 注意兼容性：
std::scoped_lock是 C++17 引入的，C++14 及更早只能用std::lock+std::adopt_lock
std::lock_guard 本身不防死锁，但配合 lock/unlock 顺序约定可降低风险
很多人误以为只要用了 std::lock_guard 就“线程安全”了，其实它只保证单个锁的自动释放，对多锁顺序毫无约束。真正防死锁靠的是工程规范，而非这个类本身。
立即学习“C++免费学习笔记（深入）”；
典型错误现象：程序偶发卡死，gdb 查看线程状态显示多个线程都停在 pthread_mutex_lock 或 std::mutex::lock()，且各自持有某锁、等待另一锁 —— 这就是典型的循环等待型死锁。
- 所有模块必须约定全局一致的锁顺序，例如“总是先锁
g_config_mutex，再锁g_cache_mutex”，并在注释和代码审查中强制检查 - 避免在持有锁期间调用用户可扩展的回调（如 std::function）、虚函数或第三方库接口，这些可能间接触发未知的锁请求
- 不要在析构函数里试图获取另一把锁 —— 析构时机不可控，极易打破锁顺序
std::scoped_lock 的性能开销比 std::lock_guard 略高，但通常可忽略
std::scoped_lock 构造时需协调多个互斥量，内部可能调用多次 try_lock() 并做指数退避，相比单锁的 std::lock_guard 多几条指令和一次潜在的短暂自旋。但在绝大多数实际负载下，这点差异远小于锁本身的竞争开销。
真正影响性能的是锁粒度和持有时间，不是选哪个 RAII 类型。别为了省几个 CPU 周期而放弃死锁防护。
- 如果只锁一个互斥量，
std::lock_guard和std::scoped_lock行为一致，性能无差别 - 若锁两个以上互斥量，
std::scoped_lock的死锁避免逻辑会带来微小但确定的额外成本；不过比起死锁导致的服务不可用，这点成本几乎不值一提 - 不要手动实现“先 try_lock 再 fallback”来模拟
std::scoped_lock—— 标准库的实现已针对常见平台做了优化，自己写容易漏掉边界情况
std::scoped_lock 不解决嵌套锁、条件竞争或逻辑错误
它只管“多锁同时获取时不发生死锁”，其他并发问题一概不处理。比如两个线程都用 std::scoped_lock(mtx1, mtx2)，但一个读 data1 写 data2，另一个读 data2 写 data1，照样可能因数据依赖产生逻辑错误。
还有更隐蔽的坑：std::scoped_lock 不能跨作用域传递，也不能复制。下面这段代码编译失败，但新手常以为能“转移锁权”：
// ❌ 编译错误：std::scoped_lock 不可复制 std::scoped_lock l(mtx1, mtx2); auto l2 = std::move(l); // 即使 move 也不行，它没有移动构造函数
- 锁的作用域必须清晰，避免在 lambda 捕获后延长生命周期，尤其不能捕获到异步任务里
- 它不阻止数据竞争 —— 如果你忘了用锁保护某个共享变量的访问，
std::scoped_lock不会报错也不会警告 - 异常安全没问题（构造失败则不持有任何锁，成功则析构自动释放），但别指望它帮你发现遗漏的临界区
最麻烦的从来不是怎么加锁，而是判断“这里到底该不该加锁”“该锁哪几个变量”“有没有漏掉某个并发修改点”。标准库工具只执行指令，不理解业务逻辑。
