std::scoped_lock比std::lock_guard更安全，因其支持多互斥量自动死锁避免、异常安全的统一加锁/解锁、构造失败自动回滚，且无需手动指定顺序。
std::scoped_lock 能彻底避免死锁，但前提是所有线程按相同顺序请求互斥量——它本身不强制顺序，只保证原子性释放和异常安全。
为什么 std::scoped_lock 比 std::lock_guard 更安全
std::lock_guard 只支持单个互斥量；多个时必须手动调用 std::lock() + 多个 lock_guard，极易漏掉 unlock 或异常时析构不全。
std::scoped_lock 是 C++17 引入的“多互斥量 RAII 封装器”，内部自动调用 std::lock（使用死锁避免算法），且所有互斥量在构造时统一获取、析构时统一释放。
- 构造失败（如被中断）时，已加锁的互斥量会自动回滚，不会残留锁定
- 支持任意数量的互斥量类型（
std::mutex、std::shared_mutex等可混用） - 不依赖用户指定加锁顺序，内部用
std::lock的试探-回退策略规避死锁
正确用法：构造即加锁，作用域结束自动解锁
直接把多个互斥量传给 std::scoped_lock 构造函数。它会在构造完成前确保全部加锁成功，否则抛出 std::system_error（如因中断失败）。
std::mutex mtx_a, mtx_b;
int data_a = 0, data_b = 0;
void transfer() {
// 安全：自动处理 mtx_a 和 mtx_b 的加锁/解锁，包括异常路径
std::scoped_lock lock(mtx_a, mtx_b);
data_a += 10;
data_b -= 10;
} // 这里自动 unlock(mtx_a) 和 unlock(mtx_b)
- 不要提前声明再初始化：
std::scoped_lock<:mutex std::mutex> lock;不合法 —— 必须在构造时传入互斥量 - 类型推导更简洁：
std::scoped_lock lock(mtx_a, mtx_b);编译器自动推导模板参数 - 若需延迟构造（极少见），可用
std::defer_lock配合std::scoped_lock的重载，但失去死锁防护优势
常见误用与陷阱
std::scoped_lock 不是万能解药。它无法防止逻辑级死锁（比如不同线程以不同顺序调用不同 scoped_lock 组合）。
立即学习“C++免费学习笔记（深入）”；
- 错误模式：
thread1锁mtx_a再锁mtx_b；thread2锁mtx_b再锁mtx_a—— 即使各自用std::scoped_lock(mtx_a, mtx_b)和std::scoped_lock(mtx_b, mtx_a)，仍可能死锁（因为std::lock的算法在某些实现中不保证跨线程全局顺序） - 不支持超时：
std::scoped_lock没有类似std::unique_lock::try_lock_for的接口；需要超时请改用std::unique_lock+std::try_lock - 不能转移或复制：
std::scoped_lock移动后原对象失效，且不可拷贝 —— 设计上就是栈绑定、作用域限定
和 std::unique_lock + std::lock 的对比
功能上，std::scoped_lock(mtx_a, mtx_b) ≈ std::unique_lock<:mutex> l1(mtx_a, std::defer_lock); std::unique_lock<:mutex> l2(mtx_b, std::defer_lock); std::lock(l1, l2);，但更简洁、更难出错。
- 性能几乎无差别：两者底层都调用同一套
std::lock实现 - 可读性差异大：
scoped_lock一行表达意图；手动组合容易漏std::defer_lock或写错参数顺序 - 维护成本低：后续增减互斥量只需改构造参数，不用同步调整多行 lock/unlock
真正容易被忽略的是：即使用了 std::scoped_lock，若系统中存在其他代码用裸 lock()、try_lock() 或 lock_guard 混用同一组互斥量，整体加锁顺序依然可能失控。安全的前提是统一约定、全项目收敛到一种多锁模式。
