std::scoped_lock是C++17起唯一推荐的多互斥量RAII锁工具，要求所有参数为非const左值引用，不支持临时对象、const引用、重复锁同一互斥量、超时或手动解锁，仅适用于简单短时加锁场景。
std::scoped_lock 是 C++17 起唯一推荐的、能安全同时锁定多个互斥量的 RAII 方式；它不是 lock_guard 的多参数升级版，而是专为“多锁 + 零死锁 + 强异常安全”设计的独立工具。
构造时传参必须是左值引用，不能是临时对象或 const 引用
编译失败是最常见的第一道门槛。std::scoped_lock 构造函数要求所有参数都是非 const 的左值引用（即变量名本身），因为内部要调用 std::lock，而 std::lock 只接受可修改的 Lockable&。
- ✅ 正确：
std::scoped_lock lock(mtx1, mtx2);（mtx1、mtx2是已定义的std::mutex变量） - ❌ 错误：
std::scoped_lock lock(std::mutex{}, mtx2);（临时std::mutex{}无法绑定非 const 左值引用） - ❌ 错误：
std::scoped_lock lock(const_cast<const std::mutex>(mtx1), mtx2);</const>（const 引用不满足Lockable概念） - ⚠️ 注意：即使你只传一个互斥量，比如
std::scoped_lock lock(mtx);，语法合法，但它仍强制要求该参数是左值 —— 这和std::lock_guard的语义已不同，别误以为是兼容写法
重复传入同一互斥量会导致未定义行为
语法上允许 std::scoped_lock lock(mtx, mtx);，但运行时极可能卡死或抛 std::system_error。这不是编译期检查项，而是逻辑错误。
- 它不会帮你去重，也不会报错提示；
std::lock内部对同一对象多次加锁的行为是未定义的 - 如果你发现需要“锁同一个 mutex 多次”，说明临界区划分或数据结构设计有问题 —— 应检查是否真需多把锁，或改用
std::recursive_mutex（但通常更建议重构） - 调试时若线程突然 hang 住，且堆栈停在
std::scoped_lock构造函数内，优先排查参数是否重复
混合类型互斥量可以共存，但必须都满足 Lockable 概念
std::scoped_lock 支持同时锁定 std::mutex、std::shared_mutex、std::recursive_mutex，甚至自定义类型，只要它们提供 lock()、unlock()、try_lock() 成员函数。
立即学习“C++免费学习笔记（深入）”；
- ✅ 合法：
std::scoped_lock lock(mtx, sh_mtx);（mtx是std::mutex，sh_mtx是std::shared_mutex） - ❌ 非法：传入
std::unique_lock<:mutex></:mutex>或其它锁管理器对象 —— 它只接受原始互斥量实例，不接受“已封装的锁” - ⚠️ 注意：
std::shared_mutex的lock()是排他写锁，不是共享读锁；想用共享模式得换std::shared_lock，但那不属于scoped_lock的职责范围
没有延迟锁定能力，也不支持手动解锁或超时
std::scoped_lock 的设计哲学是「构造即抢锁，析构即释放」，它不提供任何中间状态控制接口。
- ❌ 不支持
try_lock_for、try_lock_until—— 若需超时，必须换用std::unique_lock - ❌ 不支持
unlock()或提前释放某一把锁 —— 所有锁生命周期完全绑定到作用域 - ❌ 不支持
std::defer_lock等策略标签 —— 它只有两种构造方式：scoped_lock(mtx...)和scoped_lock(std::adopt_lock, mtx...)（后者仅用于接管已由std::lock成功获取的锁） - ? 场景判断：如果临界区逻辑复杂、需条件等待、或锁持有时间不可控，
scoped_lock就不是合适选择 —— 它只适合“简单、短时、确定性加锁”的场景
最易被忽略的是它的“单向性”：它不关心你传参顺序，但极度依赖互斥量对象本身的生命周期 —— 若某个 std::mutex 在 scoped_lock 作用域内被 move 走或析构，行为未定义。确保所有传入的互斥量在整个锁持有期间都有效且未被转移。
