std::scoped_lock通过内部对互斥量地址排序并依次加锁，从源头避免死锁；要求所有锁初始未被持有，不支持递归锁，异常安全且无额外开销。
std::scoped_lock 构造时就按固定顺序加锁
它内部对所有传入的 std::mutex 指针做排序（基于地址），再依次调用 lock()，确保多个线程以相同顺序获取锁。这是避免死锁的核心机制——不是靠“尝试加锁”或“超时”，而是从源头消除加锁顺序不一致的可能。
常见错误是手动写多个 lock() 调用，比如：
mtx1.lock(); mtx2.lock(); // 顺序依赖调用位置，多线程下极易形成环路
正确做法是把所有互斥量一次性交给 std::scoped_lock：
std::scoped_lock lock(mtx1, mtx2, mtx3); // 安全，自动排序并加锁
使用场景包括：需要原子地更新跨多个数据结构的状态（如两个容器间的元素转移）、银行账户间转账、图节点与边锁协同操作等。
立即学习“C++免费学习笔记（深入）”；
不能用于已加锁的互斥量或递归锁
std::scoped_lock 假设所有传入的互斥量都处于未锁定状态。如果某个 std::mutex 已被当前线程持有，构造会阻塞甚至死锁（标准未定义行为，实际常卡住）。
容易踩的坑：
- 误将
std::recursive_mutex传给std::scoped_lock—— 它不支持递归语义，且仍会尝试重新加锁导致未定义行为 - 在已持有某锁的函数内，又用
std::scoped_lock包含该锁 —— 即使是不同作用域，也会触发重复加锁 - 混用
std::lock_guard和std::scoped_lock管理同一组锁 —— 不必要，且易引发理解混乱
参数差异：它接受任意数量的可锁定类型（Lockable），但必须全部满足“不抛异常的 lock() / unlock()”要求；std::mutex、std::timed_mutex 都行，但 std::shared_mutex 的 lock_shared() 不适用。
相比 std::lock + std::lock_guard，更简洁且异常安全
std::scoped_lock 是 C++17 引入的“一站式”方案，把加锁和 RAII 封装进一个对象。而老写法要两步：
std::lock(mtx1, mtx2);<br>std::lock_guard<std::mutex> g1(mtx1, std::defer_lock);<br>std::lock_guard<std::mutex> g2(mtx2, std::defer_lock);
不仅啰嗦，还容易漏掉 std::defer_lock 导致二次加锁崩溃。而 std::scoped_lock 在构造失败（如某锁被销毁）时会自动回滚已持有的锁，保证异常安全。
性能上无额外开销：排序只在构造时做一次指针比较，无动态内存分配；兼容性良好，只要编译器支持 C++17 即可用。
注意锁粒度与生命周期的实际边界
std::scoped_lock 对象一离开作用域就释放所有锁，这点很明确。但容易被忽略的是：它的生命周期必须严格覆盖所有需保护的操作，不能“提前析构”或“延长到无关代码”。
典型反例：
- 把
std::scoped_lock声明在 if 分支里，结果只锁了部分逻辑 - 在循环内反复构造/析构，导致频繁加解锁，拖慢性能（应把锁提到循环外，若逻辑允许）
- 误以为锁住 A 和 B 就能安全读写所有关联数据 —— 实际还需检查是否遗漏了第三个共享资源 C
复杂点在于：锁的范围必须和业务原子性一致。自动管理只是工具，不能替代对数据访问路径的梳理。
