std::scoped_lock是C++17引入的多互斥量自动锁管理器，通过内部调用std::lock避免死锁，并按构造逆序释放锁；不支持右值、延迟锁定，不可复制移动，适用于进作用域即全锁、出作用域即全放的场景。
std::scoped_lock 是 C++17 引入的多互斥量自动锁管理器
它不是 std::lock_guard 的简单升级版，而是专为「同时锁定多个 std::mutex（或任意可锁类型）」设计的安全封装。核心价值在于：自动调用 std::lock 避免死锁，且在作用域结束时按构造顺序的逆序释放所有锁。
为什么不能直接用多个 std::lock_guard？
直接写 std::lock_guard<:mutex> g1(m1), g2(m2);</:mutex> 会出问题——两个构造函数调用顺序未定义，可能先锁 m2 再锁 m1，而另一段代码反着来，导致经典 AB-BA 死锁。更糟的是，即使你手动调用 std::lock(m1, m2)，后续还得自己配对 std::lock_guard，容易漏掉或顺序错乱。
-
std::scoped_lock内部调用std::lock（带死锁避免算法），确保所有互斥量以无冲突方式获取 - 它支持任意数量的可锁类型（
std::mutex、std::recursive_mutex、甚至自定义满足 Lockable 概念的类型） - 构造失败（如某互斥量被
try_lock拒绝）时，已锁住的会自动回滚，不会留下半锁状态
std::scoped_lock 的典型用法和参数陷阱
最常用形式是直接传入多个互斥量引用，但要注意几个关键点：
- 所有参数必须是左值引用；传右值（如临时对象）会编译失败：
std::scoped_lock lk(std::mutex{});❌ - 不支持延迟锁定（没有类似
std::defer_lock的 tag）；如果需要手动控制锁定时机，得换用std::unique_lock+std::lock - 性能上比单个
std::lock_guard略重（需额外调度开销），但多锁场景下这是必要代价，别为了省一点 cycle 而手写裸lock/unlock - 示例：安全地交换两个受保护资源的值
std::mutex m1, m2;
int data1 = 0, data2 = 0;
void safe_swap() {
std::scoped_lock lk(m1, m2); // 自动死锁规避
std::swap(data1, data2);
}
和 std::unique_lock + std::lock 比，什么时候该选 scoped_lock？
如果你只需要「进作用域就全锁、出作用域就全放」，std::scoped_lock 更简洁、更难出错；一旦涉及条件判断、分阶段加锁、或需要转移所有权（比如返回锁），就必须用 std::unique_lock。
立即学习“C++免费学习笔记（深入）”；
-
std::scoped_lock不可移动、不可复制，生命周期完全绑定作用域 - 它没有
unlock()或try_lock()成员函数，没法中途释放某个锁 - 跨线程传递锁？不行。想把锁“交给”另一个函数处理？得用
std::unique_lock - 兼容性注意：C++17 起才有；旧项目若需支持 C++14，只能用
std::lock+ 多个std::lock_guard（手动保证解锁顺序）或自行封装
std::scoped_lock 前已经部分加锁了，那等于自己绕过它的安全机制。 
