std::scoped_lock构造时一次性获取所有互斥量并自动回滚，天然防死锁；必须传入可移动的Lockable左值对象，不可传指针或引用；要求互斥量生命周期长于其自身，且多锁场景需统一使用scoped_lock或lock+lock_guard。
std::scoped_lock 构造时就完成所有互斥量的上锁，天然防死锁
它不是「依次 try_lock 再重试」，而是用类似 std::lock 的算法（如等待图检测或固定顺序）一次性获取全部互斥量，避免了传统嵌套 lock() 时因加锁顺序不一致导致的死锁。只要所有线程都用 std::scoped_lock（或 std::lock）统一管理多互斥量，死锁风险就从逻辑层面被消除了。
必须传入多个互斥量对象，不能传指针或引用别名
常见错误是试图传 &mtx1 或 std::ref(mtx1)，这会导致编译失败——std::scoped_lock 要求参数是可移动、可销毁的互斥量左值，且类型需满足 Lockable 概念。正确写法是直接传对象名：
std::mutex mtx1, mtx2, mtx3;
std::scoped_lock lock{mtx1, mtx2, mtx3}; // ✅ 正确
// std::scoped_lock lock{&mtx1, &mtx2}; // ❌ 编译错误
// std::scoped_lock lock{std::ref(mtx1), mtx2}; // ❌ 不匹配类型
构造失败会抛出异常，务必确保析构安全
如果某个互斥量处于不可用状态（如已被销毁、或非标准实现下抛异常），std::scoped_lock 构造可能抛 std::system_error。此时已成功加锁的互斥量会自动回滚释放——这是它比手写 std::lock + 多个 unlock() 更安全的关键。但要注意：
- 所有互斥量对象在
std::scoped_lock生命周期内必须保持有效（不能提前析构） - 不要在构造
std::scoped_lock时混用其他同步原语（如std::shared_mutex），除非确认其满足Lockable要求 - 若使用自定义互斥量，需显式支持
lock()、try_lock()、unlock()且无副作用
和 std::lock_guard 不能混用同一组互斥量
一个互斥量同时被 std::scoped_lock 和 std::lock_guard 管理，不会报错，但会破坏原子性保障。例如：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
std::mutex mtx1, mtx2;
{
std::scoped_lock lk1{mtx1, mtx2}; // 同时锁两个
// ...
{
std::lock_guard lk2{mtx1}; // 单独再锁 mtx1 → 可能死锁或 UB
}
}
这种写法看似无害，实则绕过了 scoped_lock 的全局顺序协商机制。多互斥量协作时，所有相关锁操作应统一用 std::scoped_lock 或统一用 std::lock + 手动 lock_guard，不能交叉。
真正容易被忽略的是：互斥量对象本身的生命周期和作用域——它们比 std::scoped_lock 实例活得更短，或者被 move 出作用域，都会让自动解锁失效，变成悬空锁持。这不是 API 问题，而是资源管理契约没守牢。
