scoped_lock 是c++17引入的专为多互斥锁设计的原子加锁工具，能自动按地址顺序加锁避免死锁，支持任意满足lockable概念的互斥类型，构造即加锁、析构自动解锁且强异常安全，不支持单锁优化用法或重复传入同一互斥量。
scoped_lock 是什么，为什么不用 lock_guard
它不是“升级版 lock_guard”，而是专为多互斥锁设计的原子加锁工具。当你需要同时锁定 mutex_a 和 mutex_b，又怕死锁（比如线程1先锁A再锁B，线程2反过来），scoped_lock 会自动按地址顺序加锁，避免死锁——这是 lock_guard 根本做不到的。
常见错误现象：lock_guard 套两个实例，或手写 mtx1.lock(); mtx2.lock();，一旦中途异常或顺序不一致，极易卡死。
- 必须用
std::scoped_lock（C++17 起），别手写 try-lock 循环 - 支持任意数量的互斥类型：
std::mutex、std::shared_mutex、甚至自定义满足 Lockable 概念的类型 - 构造即加锁，析构自动解锁，RAII 安全，且全程无异常抛出（
noexcept）
怎么正确声明和初始化 scoped_lock
不能只传一个 mutex 就以为“兼容 lock_guard”——虽然语法上能过，但语义已不同：单个参数时它退化为等效于 lock_guard，但失去了多锁排序能力；更重要的是，它仍要求所有参数在构造时就全部可访问、未被 move 走。
典型误用：scoped_lock lk(std::move(mtx)); —— 错，scoped_lock 不接受右值引用；scoped_lock lk(mtx1, mtx2); 才是正解。
立即学习“C++免费学习笔记（深入）”；
- 所有互斥量必须是左值，且生命周期需长于
scoped_lock对象 - 支持混合类型：例如
scoped_lock lk(mtx, shared_mtx);（前提是都满足 Lockable） - 不支持延迟加锁（不像
std::defer_lock那样），构造即抢锁，失败则抛std::system_error
和 std::lock + lock_guard 组合比有什么区别
老写法：std::lock(mtx1, mtx2); 然后分别用 lock_guard 包裹——看似等效，实则多一层风险：如果 lock 成功但某个 lock_guard 构造失败（比如内存分配异常），已锁的互斥量不会自动释放。
scoped_lock 把“加锁 + RAII 封装”合并为原子操作，内部调用 std::lock，但任何一步失败都会回滚已获取的锁（通过 unlock 调用），保证强异常安全。
-
scoped_lock构造函数是noexcept(false)，但失败时已持有的锁必被释放 - 性能上无额外开销：和手写
std::lock+ 双lock_guard几乎一致，只是更安全 - 兼容性注意：C++14 及更早不支持，得用
std::lock+lock_guard手动组合
容易被忽略的边界情况
最常踩的坑不是语法，而是锁粒度与对象生命周期错位。比如把局部 std::mutex 成员传给跨作用域的 scoped_lock，或者在 lambda 捕获中隐式延长了锁的持有时间。
另一个隐形问题：scoped_lock 对同一互斥量重复传入，例如 scoped_lock lk(mtx, mtx); —— 行为未定义，多数实现会死锁或崩溃，编译器不报错。
- 禁止传入相同互斥量的多个引用（哪怕变量名不同，地址一样也不行）
- 若需递归加锁，请用
std::recursive_mutex+lock_guard，scoped_lock不提供递归语义 - 调试时注意：GDB 或 ASan 无法直接显示
scoped_lock持有状态，得靠日志或检查 mutex 的try_lock()返回值来间接验证
scoped_lock 不是“可选优化”，而是防止死锁的最小必要封装；但它的安全前提，是你真的理解每个传入的互斥量从哪来、到哪去、谁在用。 
