std::scoped_lock是C++17引入的RAII工具，用于同时、原子地获取多个互斥量以避免死锁；它专为多锁场景设计，而std::lock_guard仅支持单锁，混用会导致未定义行为或死锁。
std::scoped_lock 是什么，为什么不用 std::lock_guard
std::scoped_lock 是 C++17 引入的 RAII 工具，用于**同时、原子地获取多个互斥量（std::mutex 及其派生类）**，天然避免死锁。它不是 std::lock_guard 的升级版，而是专为多锁场景设计的替代方案——std::lock_guard 只支持单个互斥量，强行套用多个会导致未定义行为或死锁。
常见错误现象：手写 mu1.lock(); mu2.lock(); 或嵌套 std::lock_guard，一旦线程调度顺序不一致（比如线程 A 先锁 mu1 再等 mu2，线程 B 先锁 mu2 再等 mu1），立刻死锁。
- 必须所有互斥量类型可转换为同一底层锁类型（如都是
std::mutex、std::recursive_mutex，但不能混用std::mutex和std::shared_mutex） - 构造时自动调用
std::lock算法（带回退重试），保证“全锁成功”或“全不锁”，不存在只锁住前几个的情况 - 析构时按构造逆序释放（与
std::lock_guard一致），但顺序由编译器确定，不可依赖
怎么正确声明和初始化 std::scoped_lock
声明方式直接、无模板推导陷阱：std::scoped_lock 的模板参数是互斥量类型列表，构造函数参数是对应互斥量对象的左值引用。
错误写法：std::scoped_lock<auto>(mu1, mu2)</auto>（C++17 不支持 auto 模板参数推导）、std::scoped_lock(mu1, mu2)（缺少显式模板参数，编译失败）
立即学习“C++免费学习笔记（深入）”；
- 正确写法（推荐）：
std::scoped_lock lock{mu1, mu2};—— C++17 起支持类模板参数推导（CTAD），前提是互斥量类型明确且可推导 - 兼容写法（显式指定）：
std::scoped_lock<:mutex std::mutex> lock{mu1, mu2};</:mutex> - 混合类型允许（只要都支持
lock()/unlock()）：std::scoped_lock<:mutex std::recursive_mutex> lock{mu1, rm};</:mutex> - 不能用右值临时 mutex：
std::scoped_lock{std::mutex{}, std::mutex{}}是错的——互斥量不可拷贝、不可移动，必须传左值
std::scoped_lock 和 std::unique_lock 能一起用吗
可以，但目的不同：std::scoped_lock 仅用于「构造即加锁、析构即解锁」的短生命周期临界区；而 std::unique_lock 支持延迟锁定、条件变量配合、手动解锁/重锁等灵活操作。
典型误用：试图用 std::scoped_lock 管理一个需要配合 std::condition_variable::wait 的锁——这不行，因为 wait 要求锁能被临时释放，而 scoped_lock 不提供 unlock() 接口。
- 多锁 + 条件等待 → 必须用
std::unique_lock数组 +std::lock手动加锁，再用std::scoped_lock替代不了 - 多锁 + 纯临界区保护（无 wait、无超时、无转移）→
std::scoped_lock是最简、最安全选择 - 性能影响极小：内部仍调用
std::lock，与手写std::lock(mu1, mu2)+ 多个std::unique_lock开销基本一致，但代码更清晰、异常安全更强
容易忽略的兼容性和陷阱
看似简单，但几个细节常导致编译失败或逻辑错误：
- C++ 标准库实现差异：MSVC 从 19.20（VS 2019）起完整支持 CTAD；GCC 7+、Clang 5+ 支持，但 GCC 7.1 前有 CTAD bug，建议显式写模板参数或升级工具链
- 自定义互斥量需满足 Lockable 概念：提供
lock()、unlock()、try_lock()，否则std::scoped_lock构造失败 - 不要在
std::scoped_lock构造后修改其管理的互斥量对象（比如 move 走、析构），会导致析构时对已销毁对象调用unlock() - 嵌套作用域中重复使用同名变量（如外层
std::scoped_lock lock{m1}，内层又std::scoped_lock lock{m1, m2}）会引发遮蔽，编译通过但逻辑混乱
真正关键的是：它解决的不是“要不要加锁”，而是“多个锁之间怎么不互相卡住”。只要涉及两个及以上互斥量的协同访问，std::scoped_lock 就该是默认选择——除非你明确需要延迟锁定或条件变量交互。
