std::scoped_lock能防同一批锁的循环等待死锁，因其原子性按地址升序加锁且传参顺序无关；但不能防跨函数调用链的锁序失控、混合锁类型误用、重复传同一互斥量或业务逻辑层锁序错误。
死锁不是“会不会发生”，是“什么时候触发”——只要两个线程以不同顺序申请同一组 std::mutex，且都已持有一个再等另一个，程序就会永久卡在 lock() 或 std::scoped_lock 构造里，gdb 显示停在 __pthread_mutex_lock，CPU 占用归零。
std::scoped_lock 能防什么、不能防什么
std::scoped_lock 是 C++17 起最直接有效的多锁顺序防护手段，但它只解决“同一批锁”的原子获取问题。
- 它内部调用
std::lock，按std::mutex*地址升序尝试加锁，传参顺序无关：std::scoped_lock(mtx_b, mtx_a)和std::scoped_lock(mtx_a, mtx_b)行为完全一致 - 不支持
std::shared_mutex的shared_lock，也不兼容std::timed_mutex（除非显式指定模板参数） - 析构时自动释放全部锁，没有
unlock()接口；想提前释放？说明临界区该拆分了 - 它不解决跨函数调用链中的锁序失控：比如
f1()拿了mtx_a后调用f2()，而f2()又去拿mtx_b—— 若f2()在别处被已持mtx_b的函数调用，就可能形成环
为什么 std::lock + unique_lock(defer_lock) 仍需谨慎
这个组合能原子性获取多个锁，但容易因使用方式失守而失效。
- 必须用
std::defer_lock构造所有std::unique_lock，再统一调用std::lock(lk1, lk2)；若漏掉一个defer_lock，或中途手动调lk1.lock()，就绕过了原子性保障 -
std::lock失败时会释放已得锁并重试，但重试次数和时机不可控；高竞争下可能反复失败，甚至引发活锁 - 禁止混合使用：
std::lock_guard直接构造（隐式加锁）和std::unique_lock+defer_lock在同一作用域内混用，逻辑断裂点极难追踪 - 它不校验锁的语义层级——比如转账时先锁收款方再锁付款方，
std::lock照样执行，但业务上已错乱
层次锁（Hierarchical Lock）怎么落地才不踩坑
层次锁靠运行时检查强制升序加锁，但实际部署中三个边界极易失效。
立即学习“C++免费学习笔记（深入）”；
- 必须用
thread_local std::vector<int></int>记录当前线程已持锁层级，否则多线程互相覆盖检查结果 - 构造函数里做
level_ 比较并抛 <code>std::logic_error；静默忽略或返回错误码等于放弃防护 - 禁止在析构函数里调其他锁、日志、虚函数或任何可能间接申请锁的代码，否则二次触发检查导致崩溃或死锁
- 最容易被忽略的是：所有锁必须走同一封装入口；一旦有人绕过
HierarchicalLock直接调mtx.lock()，整套机制即刻失效
调试阶段必须开的检测开关
生产环境靠设计预防，调试阶段靠工具暴露隐患——仅靠代码逻辑无法穷举所有调用路径。
- 启用 GCC/Clang 的
-D_GLIBCXX_DEBUG（libstdc++ 调试模式），它会在std::mutex重复 lock、unlock 未匹配等场景下 abort - Linux 下用
valgrind --tool=helgrind运行，它能捕获锁顺序不一致、潜在循环等待等竞态模式 - 禁用所有裸
std::mutex*或std::mutex&参数传递；改用封装类（如AccountLockGuard）强制携带层级信息和校验逻辑 - 对所有跨模块、插件或回调注入的锁操作，一律改用
std::try_lock+ 显式回滚；别指望 “这次不会同时发生”
真正难的不是写对一行 std::scoped_lock，而是让所有开发者在所有调用路径上，都遵守同一套资源序号规则——地址、ID、枚举值，选一个可判定、可复现的依据，并把它焊进接口契约里。
