std::scoped_lock能避免死锁，因其构造时调用std::lock对所有互斥量地址升序排序后原子性加锁，确保线程间加锁顺序一致，杜绝“持一个等另一个”的中间态；必须一次性传入所有需锁的非const左值互斥量，分步或混用裸lock会失效。
std::scoped_lock 为什么能避免死锁
它内部用的是“按地址升序加锁”策略，多个 std::mutex 对象传入时，std::scoped_lock 会自动按内存地址从小到大依次调用 lock()，保证所有线程以相同顺序获取锁。只要所有地方都用 std::scoped_lock（而不是手写多个 lock() 调用），就不会出现 A 等 B、B 等 A 的循环等待。
怎么正确传入多个 mutex 给 std::scoped_lock
必须一次性把所有要锁的互斥量作为构造参数传入，不能分步或条件性加锁。否则就退化成手动加锁逻辑，失去死锁防护能力。
- ✅ 正确：
std::scoped_lock lock(mtx_a, mtx_b, mtx_c); - ❌ 错误：
mtx_a.lock(); mtx_b.lock();—— 顺序不可控，易死锁 - ❌ 错误：
if (cond) std::scoped_lock lock(mtx_a); else std::scoped_lock lock(mtx_b);—— 没覆盖全部竞争路径 - ⚠️ 注意：所有
std::mutex必须是左值（即有名字、可取地址），不能传临时对象或右值
std::scoped_lock 和 std::lock\_guard 的关键区别
std::scoped_lock 是 C++17 引入的，专为多互斥量设计；std::lock_guard 只支持单个互斥量，且不提供任何顺序协调机制。混用两者会导致死锁风险重现。
-
std::scoped_lock构造时自动调用std::lock(mtx1, mtx2, ...)，失败会抛异常，不会阻塞在某个中间锁上 -
std::lock_guard只能配一个互斥量：std::lock_guard<:mutex> g(mtx);</:mutex>，多锁必须自己调std::lock+ 多个lock_guard（不推荐） - 性能上，
std::scoped_lock在多锁场景下更轻量，避免了lock_guard的多次构造开销
常见误用导致死锁的场景
即使用了 std::scoped_lock，如果互斥量生命周期或作用域管理不当，仍可能引发死锁或未定义行为。
- 锁住的互斥量被提前析构（比如局部
std::mutex对象在scoped_lock还活着时就离开作用域）→ 程序崩溃 - 跨线程传递已锁定的
std::scoped_lock对象 → 编译不过（移动构造被禁用，拷贝构造被删除） - 在持有
std::scoped_lock期间调用可能间接再尝试获取同一组锁的函数（如回调、虚函数）→ 逻辑死锁，编译器无法检测 - 使用
std::recursive_mutex配std::scoped_lock无意义：递归锁本身不解决多锁顺序问题，反而掩盖设计缺陷
最常被忽略的一点：std::scoped_lock 只保“加锁顺序一致”，不保“锁粒度合理”。若一把锁横跨 IO、网络或用户输入，哪怕顺序对了，也会卡住其他线程——这不是死锁，但效果类似。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
