std::scoped_lock是C++17引入的专为多互斥量设计的RAII锁管理器，用于一次性安全锁定多个满足Lockable概念的互斥量（如std::mutex、std::shared_mutex），内部调用std::lock自动按地址顺序加锁以避免死锁，并在析构时逆序自动解锁，强异常安全；它不是lock_guard的替代品，仅在需同时锁定两个及以上互斥量时使用，单锁场景应优先选用更轻量的lock_guard。
std::scoped_lock 是什么，什么时候该用它
它不是 std::lock_guard 的替代品，而是更安全的多互斥量加锁工具——当你需要同时锁住两个或更多 std::mutex（或支持 lock()/unlock() 的其他互斥类型）时，std::scoped_lock 才真正派上用场。单个互斥量场景下，std::lock_guard 更轻量、更常见。
怎么写一个正确的 std::scoped_lock 调用
核心是传入多个互斥量对象（左值引用），它会自动调用 std::lock 实现死锁避免的原子加锁。错误写法常出现在试图传入指针或临时对象：
- ✅ 正确：
std::scoped_lock lk(mutex1, mutex2);（mutex1和mutex2是已定义的std::mutex变量） - ❌ 错误：
std::scoped_lock lk(&mutex1, &mutex2);（传指针，编译失败） - ❌ 错误：
std::scoped_lock lk(std::mutex{}, std::mutex{});（临时对象，生命周期太短，锁无效）
注意：所有互斥量必须支持 lock()、unlock() 和 try_lock()；std::shared_mutex 也兼容，但 std::shared_lock 不行——scoped_lock 只做独占锁。
和 std::lock_guard + std::lock 混用会出什么问题
有人想“手动组合”来控制锁顺序，比如先 std::lock(m1, m2) 再分别用 std::lock_guard，这看似可行，实则危险：
立即学习“C++免费学习笔记（深入）”；
- 如果
std::lock_guard构造时抛异常（比如构造函数里做别的事），unlock()不会被调用，导致死锁 -
std::scoped_lock的析构保证所有互斥量被解锁，且加锁过程本身已做死锁规避（通过std::lock的重试机制） - 混合使用还可能破坏 RAII 语义——
std::scoped_lock是原子性的“锁一组”，而分开管理就失去这个保证
性能和兼容性要注意什么
std::scoped_lock 在 C++17 引入，不支持 C++14 或更早标准；编译需开 -std=c++17（或更高）。性能上，它比手写 std::lock + 多个 lock_guard 略重一点（内部有少量元编程开销），但差异可忽略。真正影响性能的是锁竞争本身，不是封装方式。
容易被忽略的一点：std::scoped_lock 不支持延迟构造（即不能默认构造后赋值），也不支持移动——它设计为栈上即时构造、作用域结束自动释放。如果你需要动态决定锁哪些互斥量，得换用 std::unique_lock 配合手动 lock()/unlock()，但那就得自己承担死锁风险。
