std::scoped_lock能原子性获取多个互斥量并避免死锁，其内部按地址升序加锁，彻底消除因线程间加锁顺序不一致导致的循环等待；相比多个std::lock_guard，它提供RAII管理、可变参数支持及自动回滚机制。
std::scoped_lock 能原子性地获取多个互斥量，避免死锁
当需要同时锁定多个 std::mutex 时，手动用多个 std::lock_guard 容易因加锁顺序不一致引发死锁。而 std::scoped_lock 内部调用 std::lock（或等价的 deadlock-avoidance 算法），保证所有互斥量以统一、无序依赖的方式被获取——哪怕传入顺序不同，底层也会按地址升序尝试加锁，从而彻底规避因线程间加锁顺序差异导致的循环等待。
多个 std::lock_guard 无法自动避免死锁
写成这样是危险的：
std::lock_guard<std::mutex> g1(mtx_a); std::lock_guard<std::mutex> g2(mtx_b);
它会严格按代码顺序加锁，若另一线程执行：
std::lock_guard<std::mutex> g1(mtx_b); std::lock_guard<std::mutex> g2(mtx_a);
就可能形成 A→B 和 B→A 的环路。即使你“自觉”统一了加锁顺序，也难保团队其他成员或后续修改不破坏它。而 std::scoped_lock 把这个约束从“靠人遵守”变成“由类型系统和实现强制保障”。
立即学习“C++免费学习笔记（深入）”；
std::scoped_lock 还附带 RAII + 可变参数 + 移动语义支持
相比手写多个 std::lock_guard，std::scoped_lock 更简洁且不易出错：
- 单个对象管理全部互斥量生命周期，不会遗漏某个
lock_guard的声明 - 支持任意数量的互斥量类型（只要都满足
Lockable概念），包括混合std::mutex、std::shared_mutex（C++17 起） - 构造失败时（如某个互斥量被
try_lock拒绝且未指定策略），会自动回滚已获取的锁，不会留下部分加锁状态 - 移动构造/赋值被显式删除，杜绝意外转移导致的锁状态丢失
实际使用中要注意的边界情况
std::scoped_lock 的死锁避免只在**同一作用域内一次性构造**时生效。以下情况它帮不上忙：
- 分两次调用：先
std::scoped_lock{mtx_a}，再另起一个std::scoped_lock{mtx_b}—— 这仍是两个独立临界区，无顺序保障 - 跨函数传递互斥量指针并分别加锁 —— 失去编译期上下文，无法协调顺序
- 混用
std::defer_lock和手动lock()—— 绕过了std::scoped_lock的协调机制 - 互斥量对象本身地址在运行时动态变化（极少见），可能影响排序稳定性，但标准要求实现必须处理该情况
真正关键的不是“用了 scoped_lock 就绝对安全”，而是它把最容易出问题的多锁场景，压缩到了一个不可拆分、不可绕过的原子操作里。漏掉这一点，后面所有锁策略都建立在流沙之上。
